This appears to be the 'correct' behavior as per IEEE posix specs (IEEE Draft
P1003.2c). (Although I agree that it is counter-intuitive!)
Section 8.1.7
"A mask ACL entry specifies the maximum access which can be granted by any ACL
entry except the user entry for the file owner and the other entry".
This implies that with
u::abc,g:abc,o::abc,m::123 ,
the mask will only grant beneath it
u::xxx,g::123,o::xxx.
That is, it will affect the GROUP_OBJ but it won't affect the USER_OBJ or OTHER
bits AT ALL! (It will constrain the USER and GROUP entries though).
When I create I file using 'touch',the file first get the permissions as
determined by the open() function here (gnu file-utils source).
if (! no_create)
{
/* Try to open FILE, creating it if necessary. */
fd = open (file, O_WRONLY | O_CREAT | O_NONBLOCK | O_NOCTTY,
S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP | S_IROTH | S_IWOTH);
if (fd == -1)
open_errno = errno;
}
The initial mode described above is rw-rw-rw- (00666). According to 'open'
behavior, it should get permissions based on mode & ~umask. This translates to
666 & ~002 (i.e., 666 & 775) = 664... rw-rw-r--.
If there is a default ACL, the created file permission should then be
constrained by these. So... if I have a default ACL u::rwx,g::rwx,o::rwx,
nothing will change.
When I try this on an XFS partition I do indeed get rw-rw-r-- permission with a
umask of 002 and a rw-rw-rw- with a umask of 000.
If I have a default ACL u::rwx,g::r--,o::---, the 'touched' file should get
u::rw-,g::r--,o::--- perms (with either umask). It turns out that it actually
gets u::rw-,g::rw-,o::---. THIS SEEMS WRONG... The OTHER ACL was created
correctly, but not the GROUP_OBJ ACL.
See more comments embedded in your text below:
On 29-Mar-2001 Carlos Gamboa Dos Santos wrote:
> Hi...
>
> Andrew Gildfind wrote:
>>
>> On Tue, Mar 27, 2001 at 10:51:42AM -0500, John Trostel wrote:
>> > I am seeing some strange behavior with both ACL inheritance and chacl
>> > operation. Does anyone else see this or is my build faulty?
>> >
>> > I started with a freshly formatted xfs partition on /mnt/xfs_part.
>> >
>> > I set the access, default and mask ACLs for this parition as follows:
>> >
>> > [...]
>> >
>> > Not good... Shouldn't this get the default ACLs u::rwx,g::rwx,o::rwx ?
>>
>> I'm not precisely sure of the semantics of ACL inheritance, but I noticed
>> when playing around with this that the inherited ACL was modified by
>> different umasks... I'll have to look into this further.
>
> We saw the same behaviour with our builts. After a few tests, we confirmed
> that
> "umask" was changing the active mask of the ACL and therefore limiting the
> real
> accesses.
>
> But... shouldn't "umask" be ignored in ACL where a mask is present?
> Otherwise it seems that the flexibility of the ACLs is lost...
>
> For example:
>
> [cgs@cgs] umask
> 022
>
> [cgs@cgs] id
> uid=716(cgs) gid=100(users) groups=100(users),506(ad_design)
>
> [cgs@cgs] chacl -l design
> design
> [u::rwx,g:ad_design:rwx,g::---,o::---,m::rwx/u::rwx,g:ad_design:rwx,g::---,o::
> ---,m::rwx]
>
> [cgs@cgs] mkdir design/test
> [cgs@cgs] chacl -l design/test
> design/test
> [u::rwx,g:ad_design:rwx,g::---,o::---,m::r-x/u::rwx,g:ad_design:rwx,g::---,o::
> ---,m::rwx]
>
>
> Note that now the mask has the value m::r-x! And of course another user from
> geoup ad_design can't write in design/test...
>
> By setting umask to 002 we get the correct mask m::rwx (and access rights),
> but it seems "wrong"... Or am I completely mistaken?
>
No... it seems like what I would think it would do too, but it is contrary to
the (withdrawn) Posix ACL Standard, Specifically, see sections 23.1.2, 23.1.4,
and B.23.5
But... they've (almost) got it right.
Andrew: Can you comment on the behavior I percieved as a bug? Are the ACLs
being applied wrong, or am I misinterpreting the 'standard'?
--
John M. Trostel
Linux OS Engineer
Connex
jtrostel@xxxxxxxxxx
|