[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: what's to stop a developer from nuking the repository?

From: Mark D. Baushke
Subject: Re: what's to stop a developer from nuking the repository?
Date: Mon, 01 Mar 2004 09:00:05 -0800

Hash: SHA1

address@hidden 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?


> 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?

> 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
Version: GnuPG v1.2.3 (FreeBSD)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]