[Top][All Lists]

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

Re: Permissions for different modules within the same CVS repository

From: Pierre Asselin
Subject: Re: Permissions for different modules within the same CVS repository
Date: Fri, 22 Jul 2005 00:17:10 +0000 (UTC)
User-agent: tin/1.6.2-20030910 ("Pabbay") (UNIX) (NetBSD/2.0 (i386))

Michaelis, Daniel <address@hidden> wrote:
> [-- text/plain, encoding 7bit, charset: US-ASCII, 52 lines --]

> We have a need to check in different application modules within our single
> CVS repository, where the different modules are different sub-sections of
> our product.  It would be wonderful if different groups could have different
> permissions for the varying modules.. For example:

If your Unix server has access control lists, you just have to set them up
for the access rights you want.  Otherwise, you'll have to do it with classic
Unix access permisisons.

First, uncomment the "LockDir" line in your CVSROOT/config .
Otherwise, you can't give read access without at the same time
giving write access.  Create the /var/lock/cvs/ directory  with
read-write-execute permission to everyone.

Crash course in Unix permissions:
    1)  Unix files and directories have exactly one owner (a user)
        and one group.  They have a set (read-write-execute) of
        permissions for the owner, another set for the group, and
        another set for
        everybody else.
    2)  Users can belong to one or more groups.  A user can
        read/write/execute a file he doesn't own if he belongs to
        the file's group and if the group permissions say so;
        otherwise, the "everybody else" permissions control.
    3)  For directories, the "execute" permissions give the right
        to traverse the directory to its files or subdirectories.

> Module1:  Group1 has read/write, Group2 and Group3 have read, Group4 has no
> permissions (not even read)

Create a Unix group "module1".  Set the permissions for $CVSROOT/Module1/
and all the directories below it to 02775 (aka rwxrsxr-x).  With
CVS, it is the group permissions on directories that matter.  Put
everybody in Group1, but nobody else, in the Unix group "module1".
Group1 has read-write access because of the group permissions.
Group2 and Group3 only have read access because they fall under
"everyone else".

Problem: Group4 also has read access.
    a)  Create another Unix group "module1read".
    b)  Move Module1/ one level down, say to
        $CVSROOT/Module1-gate/Module1/ .
    c)  Set the Module1-gate/ directory to group "module1read",
        permissions 0750 (rwxr-x---).
    d)  Put everybody from Group1, Group2 and Group3 in "module1read".

Users in Unix groups "module1read" and "module1" have read-write access.
Users in group "module1read" but not in "module1" have read-only access.
Users not in "module1read" have no access, because they aren't allowed
to traverse $CVSROOT/Module1-gate/ .

> Module2:  Group1 and Group 2 have read/write, Group3 and 4 have no
> permissions

> Module3:  Group1 Group2, and Group3 have no permissions, Group4 has
> read/write permission

Same idea.  Each module goes one directory further down than it
normally would and has two associated Unix groups.  Readers are
put in the "modulexread" group only and developers are put in both
the "modulexread" and "modulex" group.  If a user has the second
group but not the first, that's an error on your part.

Edit your $CVSROOT/modules file to hide the "-gate" directories,

    Module1     Module1-gate/Module1
    Module2     Module2-gate/Module2
    Module3     Module3-gate/Module3

so your developers can just "cvs checkout Module1" and create a sandbox.

pa at panix dot com

reply via email to

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