Fredag den 16. januar 2004 07:19 skrev Mark D. Baushke: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Jeeva Sarma <[EMAIL PROTECTED]> 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 _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
