[Top][All Lists]

[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 ?


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

reply via email to

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