zfs discuss - Jan 2009 - POSIX permission bits, ACEs, and inheritance confusion

I am running a test system with Solaris 10u6 and I am somewhat confused as to
how ACE inheritance works. I''ve read through
http://opensolaris.org/os/community/zfs/docs/zfsadmin.pdf but it
doesn''t seem to cover what I am experiencing.

The ZFS file system that I am working on has both aclmode and aclinherit set to
passthrough, which I thought would result in the ACEs being just that - passed
through without modification.

In my test scenario, I am creating a folder, removing all ACEs and adding a
single full access allow ACE with file and directory inheritance for one user:
> mkdir test
> chmod A=user:root:rwxpdDaARWcCos:fd----:allow test
Permission check:
> ls -dV test
d---------+  2 root      root          2 Jan  6 21:17 test
          user:root:rwxpdDaARWcCos:fd----:allow

Ok, that seems to be as I intended. Now I cd into the folder and create a file:
> cd test
> touch file
Permission check:
> ls -V file
-rw-r--r--+  1 root     root           0 Jan  6 21:42 d
         user:root:rwxpdDaARWcCos:------:allow
            owner@:--x-----------:------:deny
            owner@:rw-p---A-W-Co-:------:allow
            group@:-wxp----------:------:deny
            group@:r-------------:------:allow
         everyone@:-wxp---A-W-Co-:------:deny
         everyone@:r-----a-R-c--s:------:allow

Can anyone explain to me what just happened? Why are owner/group/everyone ACEs
(corresponding to old fashioned POSIX permission bits) created and even more
strange, why are deny entries created? Is there something mandating the creation
of these ACEs? I can understand that umask might affect this, but I
wouldn''t have though that it would be causing ACEs to appear out of the
blue.

While writing this, I stumbled into this thread: http://tinyurl.com/7ofxfj. Ok,
so it seems that this is "intended" behavior to comply with POSIX. As
the author of the thread mentioned, I would like to see an inheritance mode that
completely ignores POSIX. The thread ends with Mark Shellenbaum commenting that
he will fasttrack "the behavior that many people want". It is not
clear to me what exactly he means by this.

Then I found http://docs.sun.com/app/docs/doc/819-5461/ftyxi?l=zh&a=view and
much to my confusion, the deny ACEs aren''t created in example 8-10. How
could this be? Following some playing around, I came to the conclusion that as
long as at least one ACE corresponding to owner/group/everyone exists, the extra
ACEs aren''t created:
> mkdir test
> chmod A=user:root:rwxpdDaARWcCos:fd----:allow,everyone@::fd:allow test
> ls -dV test
d---------+  3 root     root          15 Jan  6 22:11 test
         user:root:rwxpdDaARWcCos:fd----:allow
         everyone@:--------------:fd----:allow
> cd test
> touch file
> ls -V file
----------+  1 root     root           0 Jan  6 22:15 file
         user:root:rwxpdDaARWcCos:------:allow
         everyone@:--------------:------:allow

Not bad at all. However, I contend that this shouldn''t be necessary -
and I don''t understand why the inclusion of just one "POSIX
ACE" (empty to boot) makes things work as expected.

/Peter
-- 
This message posted from opensolaris.org

On Tue, Jan 06, 2009 at 01:27:41PM -0800, Peter Skovgaard Nielsen
wrote:
> > ls -V file
> ----------+  1 root     root           0 Jan  6 22:15 file
>          user:root:rwxpdDaARWcCos:------:allow
>          everyone@:--------------:------:allow
> 
> Not bad at all. However, I contend that this shouldn''t be
necessary -
> and I don''t understand why the inclusion of just one "POSIX
ACE"
> (empty to boot) makes things work as expected.
Because, IIRC, NFSv4 ACLs have an ambiguity, as to what happens if no
ACE matches the subject that''s trying to access the resource.

Nico
--

>> ls -V file
> -rw-r--r--+  1 root     root           0 Jan  6 21:42 d
>          user:root:rwxpdDaARWcCos:------:allow
>             owner@:--x-----------:------:deny
>             owner@:rw-p---A-W-Co-:------:allow
>             group@:-wxp----------:------:deny
>             group@:r-------------:------:allow
>          everyone@:-wxp---A-W-Co-:------:deny
>          everyone@:r-----a-R-c--s:------:allow
> 
> Can anyone explain to me what just happened? Why are owner/group/everyone
ACEs (corresponding to old fashioned POSIX permission bits) created and even
more strange, why are deny entries created? Is there something mandating the
creation of these ACEs? I can understand that umask might affect this, but I
wouldn''t have though that it would be causing ACEs to appear out of the
blue.
> 
> While writing this, I stumbled into this thread: http://tinyurl.com/7ofxfj.
Ok, so it seems that this is "intended" behavior to comply with POSIX.
As the author of the thread mentioned, I would like to see an inheritance mode
that completely ignores POSIX. The thread ends with Mark Shellenbaum commenting
that he will fasttrack "the behavior that many people want". It is not
clear to me what exactly he means by this.
> 
> Then I found
http://docs.sun.com/app/docs/doc/819-5461/ftyxi?l=zh&a=view and much to my
confusion, the deny ACEs aren''t created in example 8-10. How could this
be? Following some playing around, I came to the conclusion that as long as at
least one ACE corresponding to owner/group/everyone exists, the extra ACEs
aren''t created:
> 
The requested mode from an application is only ignored if the directory 
has inheritable ACES that would affect the mode when aclinherit is set 
to passthrough.  Otherwise the mode is honored and you get the 
owner@,group@ and everyone@ ACEs.


The way a file create works is something like this

1. build up ACL based on inherited ACEs from parent.  This ACL will
    often be "emtpy" when no inheritable ACEs exists.

2. Next the chmod algorithm is applied the the ACL in order to make it
    reflect the requested mode.  This step is bypassed if the ACL created
    in step 1 had any ACEs that affect the mode and aclinherit property
    is set to passthrough.
>> mkdir test
>> chmod A=user:root:rwxpdDaARWcCos:fd----:allow,everyone@::fd:allow test
>> ls -dV test
> d---------+  3 root     root          15 Jan  6 22:11 test
>          user:root:rwxpdDaARWcCos:fd----:allow
>          everyone@:--------------:fd----:allow
> 
>> cd test
>> touch file
>> ls -V file
> ----------+  1 root     root           0 Jan  6 22:15 file
>          user:root:rwxpdDaARWcCos:------:allow
>          everyone@:--------------:------:allow
> 
> Not bad at all. However, I contend that this shouldn''t be
necessary - and I don''t understand why the inclusion of just one
"POSIX ACE" (empty to boot) makes things work as expected.
> 
> /Peter
We don''t have a mode that says completely disregard POSIX.  We try to 
honor the applications mode request except in situations where the 
inherited ACEs would conflict with the requested mode from the application.


    -Mark