Ok, I think I understand the group (ORing? of the UMask and the ACL Mask) -
the ACL Mask would have to be set rwx so that the u::rwx is possible right?
The ACL Mask isn't *just* for group am I correct?
The other "concern" I have is the "mangling" when creating files as well as
directories - under this setup so long as I have a u::rwx (and hence need a
m:rwx), all files that would get created would have a rwx (and now be
"executables!") but I notice the mkdir's take on the same permissions as the
"default file" mask I set up with the chacl -b is that right or is there
two different default permissions? one for directories, one for files?
I really do appreciate your time,
Eric
----- Original Message -----
From: "Timothy Shimmin" <tes@xxxxxxxxxxxxxxxxxxxxxxx>
To: "Eric Peters" <eric@xxxxxxxxxx>
Cc: <linux-xfs@xxxxxxxxxxx>
Sent: Thursday, August 02, 2001 8:51 PM
Subject: Re: default ACL?
> Hi Eric:
>
> On Thu, Aug 02, 2001 at 03:30:27PM -0700, Eric Peters wrote:
> > I'm basically just trying to be able and delegate a group of users rw
> > permission for a directory /www and all sub directories (or there would
> > be 5 global accounts and a couple accounts could only access certain
> > sub directories / etc)
> >
> > The mask has me fairly confused I must say, in that despite having
> > g::r-x:m::rwx, the directory has g+rwx
>
> Yeah I find it weird myself.
> But it seems to be part of the standard.
> I emailed about this on June 12 to Sebastian Dransfeld.
> Below is what I wrote to Sebastian about the application of a directory
> default ACL when a file is created inside the directory:
> | When the access ACL for a file of a directory with a default ACL
> | is created, it's ACE permissions are set by _intersection_ of the
> | respective default ACEs permission bits and the mode bits of the
> | parameter to open/creat.
> |
> | So if the creat mode bits don't have the execute (x) bit set for user
> | and other (which will depend on the application you use which makes the
> | create/open call), then nor will the USER_OBJ ACEs and OTHER ACEs.
> | Which is what you (Sebastian) saw.
> | The GROUP_OBJ ACE is treated differently if a MASK ACE exists, as
> | is the case in your example above. If we have a MASK ACE (see 5.3.1.2),
> | then the GROUP_OBJ ACE is left alone, and the MASK ACE
> | is intersected with the group permission bits of the creat parameter.
> | The std group permissions bits on the file, however, are updated
> | accordingly.
> | If you did an "ls -l" on the file, then you would see that the
> | group permission bits match the MASK ACE permission bits (see 23.1.2)
> | that you see with "chacl -l".
> | (If there was no MASK ACE then the GROUP_OBJ ACE would be intersected
> | with the group permissions as expected).
> |
> | I hope I haven't confused you.
> | The standard can be equally confusing ;-)
> |
> | The withdrawn Posix ACL standard can be downloaded at:
> | http://wt.xpilot.org/posix.1e/download.html
> |
> | Andreas Gruenbacher's site has some useful info:
> | http://acl.bestbits.at
>
>
> >
> > I also want an easy way for it all to be inherited - as well as only
> > "directories" would be +x, where normal files wouldn't need the
> > executable bit set
> >
> > Are there any other utilities other than chacl for managing the ACLs?
> Nathan Scott will soon check in ported versions of Andreas'
> setfacl and getfacl ACL commands.
> (Currently, you'll need to preserve an ACE ordering in ACL specification
> for setfacl;
> however, I'll look into fixing this problem when the code is checked in).
>
> --Tim
>
>
|