-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [EMAIL PROTECTED] writes:
> > I have known others to make the cvs executable be set-gid to a 'cvs' > > group and for all directories to be owned by a user 'cvs' and group > > 'cvs' and have 'u=rwx,g=rwxs,o=' (2770) permissions for all directories. > > This does not get around the problem that files committed or new > > directories added will be owned by the user who made the change, so > > those files and directories may need a periodic cron job to change > > ownership in the tree of directories and ,v files. However, it may be > > mitigated somewhat by the user not being able to 'see' the files under > > the repository hierarchy as they are not in the group 'cvs' which only > > cvs is able to see. The downside is that you need to be very careful > > with taint checks for the verifymsg/commitinfo/loginfo/taginfo scripts. > > So, what you are saying here is that if the cvs executable is set-gid > to a group that do NOT have the users in it, those users can still > commit, checkout, etc, but will not be able to see the directory > hierarchy aside from the cvs root? Yes. > I don't understand what you mean by 'taint checks' and how they apply here. > Do you have any sort of URL reference so I can RTFM? For example, if you use perl and the egid is not the same as the gid, then perl itself will invoke taintperl. You sould be able to find information on that on the perl web site. Basically, you will need to make sure that all inputs to the scripts that are run with an egid/gid mismatch deal properly with the situation. In some cases, you may need the script to drop egid permissions lest the user be able to subvert your permissions. For example, you would need to carefully check that commits to the CVSROOT are done only by very trusted individuals so that no user may use those scripts that are executed at commit time to raise their own privledge level. > > Are you talking about an :ext: user or a :pserver: user? > > :pserver: definitely. I am not able in good conscience to recommend that anyone use :pserver: for commit access to any cvs repository at any time. Opinions on this matter differ and you will likely get a mixture of such opinions from members of this list. > > One way is to ensure that the users are only given access to the 'cvs' > > command via SSH on login. > > This I can't do since the machine is intended to be wide open > (relatively) to all users. It's an internal server with home > directories, etc... This is a not a good situation. I would strongly urge you to talk with your management and try to remedy the situation by moving to a separate machine to serve as your cvs server. > I was thinking about a different set of users, thus giving each human > two ids, one for general server access and the other strictly for CVS > over ssh. If you are serious, then you could move to a virtual machine such as is being used by many ISPs. The repository would then reside inside of a virtual machine in a chrooted environment which normal users would not be able to visit by allowing only root to access the directory that holds the chroot directory in which the virtual machine/chroot jail runs. > We are a small operation so the id duplication is not that > big of a deal, except for getting everyone to update themselves > (generating new keys, making a new user on each local machine with the > required home and .ssh directories). THEN, I can limit this other > user, and play with permissions to restrict as needed. Is this a > viable plan? It might work, but you need to consider how growth of your company will impact your development environment. > Is anybody else doing something like this? http://www.pointless.nl/~peter/stuff/cvs-server.html > This seems to be a bit of a design limitation for CVS, no? No, you are asking how to avoid casual or malicious damage to the repository. It is possible to do this, but it is not required for all users of cvs. Also, special-purpose boxes are a reasonable configuration for cvs servers and are able to provide what is needed. cvs has been around a long time and was originally not even a client/server design. If you don't like it, you are welcome to look at other systems. Version control systems of possible interest include: aegis, arch, bitkeeper, clearcase, cmsynergy, co-op, cvs, cvsnt, monotone, opencm, perforce, subversion, svk, vesta one of which may find all the features you think you want. Good luck, -- Mark -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFAQ2wV3x41pRYZE/gRAld0AKCndxhZ6iD7tv40GwsFgFP7cAgx4gCeM/NL UkBepdkAWRx7rGZAF37cSFU= =+LKG -----END PGP SIGNATURE----- _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
