[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.
Workaround:
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