Re: user permissions of files and directories

[Pierre Asselin]

Matthias Friebe <address@hidden> wrote:

> I was unsuccessfully checking several CVS documentation for user 
> permissions in CVS.

Larry already pointed you to the docs on cvshome.org, so start there.
Note the bit about "LockDir" in CVSROOT/config, which is necessary
if you plan to give read-only access to some people.


> What we want to do is give explicit read permissions to users for 
> files/directories. By default a user should have no read or write access 
> to files/directories unless we specify that they do.

Set up a LockDir and give write access to everyone.  I think
the LockDir should be 0775 + setgid and everyone should be
in the LockDir's group.

The project directories should be 0775 + setgid, with one group
per project.  The project developers need to be in the group in
question so they have write access.  Everyone else has read
access, which is more than you want.

To block read access selectively, place each project tree under a
"gatekeeper" directory, permission 0750, with yet one new group
per project.  People with read-only or read-write access access
need to be in this gatekeeper group.  Others aren't, and this is
where they lose their read access.

    /var/
        cvslock/        rwxrsxr-x       lockgrp

    $CVSROOT/
        proj-1-gate/    rwxr-x---       proj1grpR
            proj-1/     rwxrsxr-x       proj1grp
        proj-2-gate/    rwxr-x---       proj2grpR
            proj-2/     rwxrsxr-x       proj2grp

A user not in group lockgrp has no access.

A user in lockgrp only still has no access.

A user in lockgrp and proj1grpR has read access to project 1.

A user in lockgrp, proj1grpR and proj1grp has read-write access to
project 1.

Any other combination of lockgrp, proj1grpR and projgrp would be
an error.

Since each project is buried one directory deeper than normal
you would set up appropriate definitions in CVSROOT/modules to 
skip the intermediary "gatekeeper" directory.

If this is to be retrofitted to an existing repository, moving each
project down is going to be a one-time nuisance.  Either tell
everyone to commit their work before the move and check out new
sandboxes afterward, or let the braver ones edit their sandbox
CVS/Root directories.

-- 
pa at panix dot com