[Techtalk] cvs permissions

[Anthony de Boer]

Conor Daly wrote:
> ... 'chmod g+s $CVSROOT' to force a common gid for files and dirs ...

There's some support in CVS for running setgid, with only that gid allowed
into $CVSROOT, but it's not enabled by default in RedHat at least.

(General rant: back when a sysadmin was someone who compiled his/her own
binaries, compiletime switches were the norm, but this model does *not*
play well with someone trying to build a one-size-fits-all binary distro.)

Here are some notes from when I built a setgid CVS a few releases ago.

Per the CVS FAQ, I added a patch to hang onto its effective GID:

*** src/main.c.orig	Mon May 26 13:19:30 2003
--- src/main.c	Mon May 26 13:20:13 2003
***************
*** 422,427 ****
--- 422,430 ----
          don't use it. */
      int option_index = 0;
  
+     /* added per FAQ */
+     setgid(getegid());
+ 
  #ifdef SYSTEM_INITIALIZE
      /* Hook for OS-specific behavior, for example socket subsystems on
         NT and OS2 or dealing with windows and arguments on Mac.  */

I added CFLAGS=-DSETXID_SUPPORT:

configure --without-krb5 --without-gssapi --disable-encryption --with-cvs-admin-group=cvsadmin CFLAGS=-DSETXID_SUPPORT

and then I created a "cvs" group, set owner:group as root:cvs on both
/usr/bin/cvs and $CVSROOT, and did a chmod 2555 on the former and 770 on
the latter (possibly I should have made the directory 2770?).

This accomplishes the goal of preventing users from doing anything
manually under $CVSROOT; you can set triggers and such in cvs to
control who can do what to which files.

Users who should get poking-around permission could be added to the
/etc/group entry for cvs, but typically only the cvs admin should
ever have cause to do things in $CVSROOT.

-- 
Anthony de Boer