Re: a question on permissions

[Mark D. Baushke]

Isaac Claymore <address@hidden> writes:

> I guess my question is somewhat more about filesystems than CVS, but I
> think you guys may have had similar problems.
> 
> There're 10 members of my team, and they're in the group devp. $CVSROOT
> is thus owned by group devp, so that every team member gets read/write
> access to the repository. Meanwhile, ViewCVS and our backup daemon
> demand read access, so I had to grant read access to all others(and
> of course execute access of those directories).
>
> This means that everyone not in the group devp can get our sources by
> simply running tar over $CVSROOT(there're many users on the server
> who're not among the group). Since we're not doing open source
> projects, this'd be a very serious problem.
> 
> I'm using ext3, and I guess ext3 ACL support of 2.5.x kernels will
> solve this with ease, but I can't just sit waiting for that to appear
> in a stable kernel.
> 
> Any hint or suggestion is greatly appreciated.
> 
> Thanks.

Some questions:
  
  -> Are you able to put your backup daemon into the devp group?
     If so, then it would be able to read all of your $CVSROOT files
     and put them on backup. Of course, access to your backup media
     could be a security problem too...
  -> Are you able to have root on cvs server mirror/copy the $CVSROOT
     into another filesystem (possibly encrypted) that is able
     to be read by your backup daemon? (This is really the best way
     to deal with it if you don't really trust access to your backup
     system. Just tar up the repository and gpg encrypt the .tar.gz
     file and then copy it to a filesystem that your backup program
     can read. It does not matter if everyone else in the world can
     read it too, only those who are able to decrypt it can actually
     use the backup file.)

For ViewCVS, you should just be able to add it to group devp by making
the cgi script set-gid 'devp' on your server.

        -- Mark