Thanks to Mark, Eric and Larry. SO just to summarize, seems I have two options,
1.stop nfs method of sharing , use :pserver 2. Evenif nfs is used, i need to setid the repository and cvs Bibhas "Mark D. Baushke" wrote: > > Bibhas Kumar Samanta <[EMAIL PROTECTED]> writes: > > > Hi, > > > > I have a simple query. > > We have Solaris/unix network with NIS . > > and we use /net/<machine_name>/system/CvsRoot as our CVSROOT > > which is accessible from all machines. > > > > As CVSROOT requires write permission, it has 777 permission for > > all. > > But this essentially empower each user to delete the whole > > CVSROOT , may be even mistakenly ie > > cd /net/<machine_name>/system/CvsRoot;\rm -rf * > > > > How can I avoid that . or do I have any mechanism to log > > who is accessing the CVSROOT area. > > First, do not allow read-write NFS exporting of your repository. > This reduces access to the repository significantly. > > This will mean using either pserver or rsh/ssh to connect to the > repository for commits. This only reduces your exposure as having the > ability to rsh into your server machine could still let someone go to > the directories of the repository and access files or otherwise do harm. > > Note that cvs is not really a 'secure' source control system. There will > always be some wiggle room for creating problems. > > > Or what is the common CVSROOT structure/access mechanism > > is used by you . > > > > > > Thanks, > > Bibhas > > For myself, I believe that special-purpose machines are cheap and easy > to maintain, so I use single purpose machines as the cvs server. Users > are allowed to login via ssh for their commits and are told never to > login directly to the cvs machine. This does not stop a determined > attack against the repository. It does make is much less likely that > someone will do something accidentally. > > Another method is to define SETXID_SUPPORT when building cvs. Then make > your repositories be user and group writable and your cvs executable be > set-gid on the server machine in that group. You will need to be very > careful with your commitinfo, verifyinfo, loginfo scripts about > untainting the source to avoid holes. For best results you will also > want your loginfo script to run some kind of a script to give ownership > of all of the committed files to some user other than the user running > the cvs command. A version of 'sudo' with a rule to remove any setuid > and setgid bits and change ownership to some administrative account > owner would likely do the job. > > If the above looks fragile, it is. It will only stop unintentional > damage as there are windows of opportunity while the commit is occuring > to damage the files being modified by the commit. > > Good luck, > -- Mark > > _______________________________________________ > Info-cvs mailing list > [EMAIL PROTECTED] > http://mail.gnu.org/mailman/listinfo/info-cvs _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
