[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: need/want per module users ... need hints about developing
From: |
wim delvaux |
Subject: |
Re: need/want per module users ... need hints about developing |
Date: |
Sun, 3 Aug 2003 17:53:24 +0200 |
User-agent: |
KMail/1.5.2 |
Well i tried messing with the +s bit but it DOES get annoyingly complex.
It seems that setting the +s does not always allow you to do thing.
THe situation is now :
user : u19809.apusers
project user : apuser.apusers
this user needs access to project cwi
project user for that project : cwiuser.cwiusers
Group file : cwiusers:::apuser
CVSROOT/passwd contains u19809::apuser
So when u19809 commits the id gets translated to apuser.apusers according to
the group file that user has rights to the cwiusers group too.
Now ...
directory of module rwsrwsr-x Assembly
has a subdirectory : rwsrwsr-x behaviors
When I commit as u19809 (using pserver) I get permission denied when creating
directory #cvs.lock in Assembly/behaviors??????
Also when I su - to the apuser user and touch a file in Assembly I get the
file owned by apuser.cwiusers ? If I create a directory it has rights
rwxrwxr-x so without the +s but so that other users again cannot modify
things ...
Huh ?
W
On Saturday 02 August 2003 11:56, Brian Murphy wrote:
> wim delvaux wrote:
> >HI all,
> >
> >I have the following problem.
> >
> >a group (g1) of users (e.g u1) needing access to projects of classes P1
> > and P2
> >a group (g2) of users (e.g u2) needing access only to projects of class
> > P2.
>
> Or.. each project has it's own unix group (/etc/group) and you add the
> individual
> users to the groups corresponding to the projects they should have
> access to.
> Create the root directory in each module with "chmod g+s" permission
> and read/write access for group so that the group permissions get
> inherited when
> files get created in it.
> Use "other" permissions to give other users access to read the files (or
> not) and no
> read permissions.
> The unix owner of the file in this scenario is irelevant.
>
> /Brian