gnu-arch-users
[Top][All Lists]
Advanced

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

Re: [Gnu-arch-users] bad permissions when adding revisions to the librar


From: Pau Aliagas
Subject: Re: [Gnu-arch-users] bad permissions when adding revisions to the library
Date: Tue, 23 Dec 2003 13:33:38 +0100 (CET)

On Tue, 23 Dec 2003, Jan Hudec wrote:

> On Tue, Dec 23, 2003 at 09:33:56 +0100, Pau Aliagas wrote:
> > 
> > I want to share the revision library and to do so I've created a shared 
> > dir, with g+s permisions. People belonging to the groups should be able to 
> > store revisions there.
> > 
> > But when a library is needed and, consequently, added, I have permission 
> > problems:
> > -the dirs up to patch level preserve the group setuid bit
> > -but the directories inside don't
> > 
> > Example:
> > * /home/arch/{library} is created manually with g+s
> >   I expect all the subdirs to keep the group setuid bit
> > * /home/arch/{library}/address@hidden/web/web--prod/web--prod--1.0
> >   This one and all the preceeding are created with g+s
> > * /home/arch/{library}/address@hidden/web/web--prod/web--prod--1.0--patch-X
> >   This one does not preserve the group setuid bit, so the dirs inside are 
> >   created
> > 
> > * umask is always 0002
> > 
> > I would expect tla to always honour the group setuid bits.
> 
> Remember, that:
> a) Permissions are under revision control in arch.
> b) Revision library contains checked-out copies, where everything must
>    be exactly same as for fresh working copy (preserving copy is
>    done to get working copy from library).
> 
> Now, I guess it's clear why the setgid bits get reset within the library
> revisions...

I'm not sure that tla preserves the setuid bits, in fact I think it does 
not. But anyway I'm talking about permissions that are commited to the 
archive and lost afterwards.

Pau




reply via email to

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