Re: CVS, RSH and direct access to repository

[Claus Henriksen]

Fredag den 16. januar 2004 07:19 skrev Mark D. Baushke:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Jeeva Sarma <address@hidden> writes:
> > I want to know if there is any method to prevent users
> > from directly accessing repository.
>
> Sure. Control the access to the machine. If they do not have
> the opportunity, then it seems likely they will not be able
> to do anything directly without proper authorization.
>
> > I read of one method, using Openssh and restrict users to
> > one command,
>
> Yes, this is the an excellent approach to choose. If your
> source is important, then it deserves to be protected.
>
> > but that would prevent the users from even logging on to
> > the machine.
>
> Yes, that is true.
>
> > Some developers use this machine for other purposes (do
> > their regular development and stuff).
>
> This is a bad situation. How much would it really cost you
> to have a dedicated machine as a cvs server? How much would
> it cost if your developers damage your source repository?
> Do the risk analysis and cost analysis and see if you have
> enough justification for a dedicated cvs server. If so,
> that is the way to go.
>
> > We plan to have CVS server on solaris, windows clients
> > using ssh authentication. Pls advice.
>
> If you can do it, make the cvs server a single-purpose box,
> then you can implement restricted shells via ssh that only
> allow the cvs command to be executed. This means that only
> the cvs command may be used to modify the repository. This
> is a good situation.
>
> If that solution is not available, then you could look into
> making the cvs executable be set-gid only on the cvs server
> and have the directories that hold the repository only be
> set-gid to that group and have no users other than the
> administrator in the group (ideally only via sudo commands
> or some other mechanism that logs what happens). The
> downside here is that a user who commits or tags a file will
> end up as the owner of the file. The hack for this problem
> is to run a set-uid program that changes the ownership of
> the ,v file to a special 'cvs' account, but does so only for
> files and directories in the repository hierarchy and makes
> sure that they are only ,v files that are so updated. This
> reduces the exposure against accidental modifications to the
> repository, but may not be able to stop someone determined
> to hack the repository.
>
> While it may be possible to do some kind of hackery to get
>
> :pserver: to keep a separate userid space from your real
>
> users, I believe that way lies madness and I personally do
> not consider the :pserver: as a 'secure' option for a
> production network as anything other than a read-only
> 'guest' checkout.

Well, what then if you tunnel pserver like explained in 
http://wwwhome.cs.utwente.nl/~klaren/index.html?left.html&cvs-stunnel.html ?
Has somone experience with that? 
I got it up working alright, but I have got no true long-time experience.

/Claus