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

[Mark D. Baushke]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

address@hidden writes:

> The problem is that the cvs directory is on the same machine as all
> the other server stuff including user's server home directories. 

What you describe is a non-optimal setup. Do try to use a dedicated
machine which does not allow general purpose logins to it.

   If possible, 

     - Use a dedicated machine for your cvs server.
     - Allow access via ssh only. 
     - Provide only stub home directories with a .ssh/authorized_keys
       file that gives them their public key and restrists the command
       they are able to run to the pathname to the 'cvs' command only.

If a special-purpose machine with a minimal environment for users is not
possible, then you may need to take a bit more care about how cvs is
being used.

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.

> Thus, a user can access the server via a simple 'ssh', then do 'cd
> /cvs' and have free rein due to the permissions set below.
> 
> 1. How do you enforce a restricted shell with a chroot prison?  A hacked 
> version of ssh?

While possible, I don't think a chroot prison is necessary and a
standard version of ssh should work. However, if others are already
using this method, perhaps they can be more forthcoming in its
description...

> 2. How do I muck with the permissions so that developers can't even
> read, much less write to the cvs directory, but not damage regular cvs
> access?

As the user will likely 'own' any files that have just been operated on
via a commit or tag operation, unless you have some sort of hack that
changes the ownership of files as a part of the log_accum step, it seems
unlikely that this will do you much good at all. However, if the
top-level directories that own your repository are only able to be
penetrated by a cvs executable due to its set-gid nature, that may give
you some minor protection (I still believe a dedicated machine is a
better solution).
 
> That is, the system-wide passwd file has a user named "cvsaccess"
> ("not his real name" :-)

Are you talking about an :ext: user or a :pserver: user?

> Then, /etc/group has a group named 'cvs' with cvsaccess as well as all other 
> users that need access to CVS attached to that group.
> 
> 'cvsaccess' is also listed in the CVSROOT/writers file.

The writers files is intended to be a :pserver: feature... let me be
clear, I know that many people use :pserver:.

Note: I do not consider the :pserver: feature to be useful for anything
other than anonymous read-only access to a mirror of the master
repository. It was and is a fairly insecure hack that I would rather see
removed from cvs. So, I am probably the wrong person to ask about how to
use it to allow writers...

> All objects in the /cvs directory are owned by cvsaccess/cvs with all files 
> having 444 permissions, the directories having 775 permissions.  This is a 
> mess.  Since the same user that accesses the main server via ssh has write 
> permissions due to membership in the 'cvs' group, this allows nuking of the 
> repository files.  How do I fix this?

One way is to ensure that the users are only given access to the 'cvs'
command via SSH on login.

> Also, would it help if I enforced a provision that all users access cvs 
> using :ext: only via ssh?  How would this work with WinCVS users?

Yes. If only ssh access may be granted to the machine, it is possible to
use the command= feature of the OpenSSH .ssh/authorized_keys file to
restrict the command the user is able to run to that of 'cvs server'
which is desirable to limit the ways in which the user may fiddle with
files in the repository.

Both cvs.exe and TortoiseCVS users on windows boxes seem to have been
able to use PuTTY and Pageant (PuTTY's ssh agent) to access cvs servers
using :ext: over the SSHv2 protocol.

        Enjoy!
        -- Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)

iD8DBQFAQgxO3x41pRYZE/gRAudSAJ4oOh4d8dQ1MrhqeQ84b4i/BX9hDACdFDZM
wZ6DGJyLSTpefR9y4RqF0mM=
=hibW
-----END PGP SIGNATURE-----