Project

General

Profile

Bug #3571

aclinherit=passthrough and directory trees

Added by Richard PALO over 7 years ago. Updated over 3 years ago.

Status:
Feedback
Priority:
Normal
Assignee:
Category:
zfs - Zettabyte File System
Start date:
2013-02-17
Due date:
% Done:

0%

Estimated time:
Difficulty:
Medium
Tags:
needs-triage
Gerrit CR:

Description

I have a recurrent problem with a particular use-case involving inherited ACLs in a ZFS shared directory (that is generally NFS and CIFS shared as well).

when copying directory trees, the ACLs seem not to be respected.

I can easily reproduce the problem as follows in a subdirectory of $HOME:

richard@x3200:~$ zfs get aclmode,aclinherit,xattr dpool/export/home/richard
NAME                       PROPERTY    VALUE          SOURCE
dpool/export/home/richard  aclmode     passthrough    local
dpool/export/home/richard  aclinherit  passthrough    local
dpool/export/home/richard  xattr       on             default

richard@x3200: ~$ /usr/bin/mkdir testacl
richard@x3200:~$ /usr/bin/chmod A=everyone@:rwxpdDaARWcCos:fd-----:allow testacl

richard@x3200:~$ mkdir testacl/foo
richard@x3200:~$ touch testacl/foo/foo.txt
richard@x3200:~$ ls -ladV testacl/ testacl/foo/ testacl/foo/foo.txt 
drwxrwxrwx+  3 richard  staff          3 févr. 17 17:22 testacl//
              everyone@:rwxpdDaARWcCos:fd-----:allow
drwxrwxrwx+  2 richard  staff          3 févr. 17 17:22 testacl/foo//
              everyone@:rwxpdDaARWcCos:fd----I:allow
-rwxrwxrwx+  1 richard  staff          0 févr. 17 17:22 testacl/foo/foo.txt*
              everyone@:rwxpdDaARWcCos:------I:allow

up to here all is cool.
richard@x3200:~$ mkdir testacl/bar
richard@x3200:~$ /usr/bin/cp testacl/foo/foo.txt testacl/bar/
richard@x3200:~$ /usr/bin/cp -R testacl/foo testacl/bar/
richard@x3200:~$ ls -laV testacl/bar testacl/bar/foo
testacl/bar:
total 10
drwxrwxrwx+  3 richard  staff          4 févr. 17 17:24 ./
              everyone@:rwxpdDaARWcCos:fd----I:allow
drwxrwxrwx+  4 richard  staff          4 févr. 17 17:23 ../
              everyone@:rwxpdDaARWcCos:fd-----:allow
drwxrwxrwx   2 richard  staff          3 févr. 17 17:24 foo/
                 owner@:rwxp--aARWcCos:-------:allow
                 group@:rwxp--a-R-c--s:-------:allow
              everyone@:rwxp--a-R-c--s:-------:allow
-rwxrwxrwx+  1 richard  staff          0 févr. 17 17:24 foo.txt*
              everyone@:rwxpdDaARWcCos:------I:allow

testacl/bar/foo:
total 7
drwxrwxrwx   2 richard  staff          3 févr. 17 17:24 ./
                 owner@:rwxp--aARWcCos:-------:allow
                 group@:rwxp--a-R-c--s:-------:allow
              everyone@:rwxp--a-R-c--s:-------:allow
drwxrwxrwx+  3 richard  staff          4 févr. 17 17:24 ../
              everyone@:rwxpdDaARWcCos:fd----I:allow
-rwxr-xr-x   1 richard  staff          0 févr. 17 17:24 foo.txt*
                 owner@:rwxp--aARWcCos:-------:allow
                 group@:r-x---a-R-c--s:-------:allow
              everyone@:r-x---a-R-c--s:-------:allow

Yes, I said "_bollocks_" too.

Am I missing something in the semantic meaning of aclinherit and aclmode, or is there indeed something awry with directory copies?

For our installation, the users are using typically nautilus (locally and nfs) or windows explorer (cifs) and copy/paste of directory trees is quite common.

Currently I have to intervene frequently to reset the ACL.


Files

truss-gnu-cp.log (4.29 KB) truss-gnu-cp.log Richard PALO, 2013-02-20 07:13 AM

History

#1

Updated by Richard PALO over 7 years ago

By the way, I can do the following with the command line:

richard@x3200:~$ /usr/bin/mkdir foobar
richard@x3200:~$ /usr/bin/cp -rp -/ testacl/foo/ testacl/foobar/
richard@x3200:~$ ls -laV testacl/foobar/ testacl/foobar/
testacl/foobar/:
total 7
drwxrwxrwx+  2 richard  staff          3 févr. 17 17:22 ./
              everyone@:rwxpdDaARWcCos:fd----I:allow
drwxrwxrwx+  5 richard  staff          5 févr. 17 17:44 ../
              everyone@:rwxpdDaARWcCos:fd-----:allow
-rwxrwxrwx+  1 richard  staff          0 févr. 17 17:22 foo.txt*
              everyone@:rwxpdDaARWcCos:------I:allow

testacl/foobar/:
total 7
drwxrwxrwx+  2 richard  staff          3 févr. 17 17:22 ./
              everyone@:rwxpdDaARWcCos:fd----I:allow
drwxrwxrwx+  5 richard  staff          5 févr. 17 17:44 ../
              everyone@:rwxpdDaARWcCos:fd-----:allow
-rwxrwxrwx+  1 richard  staff          0 févr. 17 17:22 foo.txt*
              everyone@:rwxpdDaARWcCos:------I:allow

But again, not with nautilus or explorer.

#2

Updated by Richard PALO over 7 years ago

just tried with a simple archive containing a directory structure (zip).

Only the top level directory is created seemingly ok, all children (files and directories) exhibit the same above mentioned problems. If I descend in the directory and manually create files or directories, all seems ok (e.g. with mkdir and touch).

#3

Updated by Richard PALO over 7 years ago

perhaps to be more clear, the acl set is equivalent to:

$ /usr/bin/chmod A=everyone@:full_set:file_inherit/dir_inherit:allow testacl

Being unfamiliar with the code, http://src.illumos.org/source/xref/illumos-gate/usr/src/uts/common/fs/zfs/zfs_acl.c seems a bit terse to me at first look.

I did notice some aclinherit tests in illumos-gate:
http://src.illumos.org/source/xref/illumos-gate/usr/src/test/zfs-tests/

Would it be helpful to try to come up with a testsuite with this use-case? (if these are actually run for regression testing)

Could anyone knowledgeable at least confirm the issue, that it isn't a flagrant cockpit error?

Perhaps it's above the zfs subsystem, but I'm initially inclined to doubt it...

#4

Updated by Paul Henson over 7 years ago

cp chmod's the directory when it copies it:

$ mkdir testdir
$ chmod A=everyone@:rwxpdDaARWcCos:fd:allow testdir
$ mkdir testdir/two
$ truss cp -r testdir/two testdir/three 2>/tmp/truss.out
$ ls -Vd testdir/two testdir/three

drwxrwsrwx+ 2 henson csupomona 2 Feb 19 13:11 testdir/three
everyone@:rwxpdDaARWcCos:fdi---:allow
owner@:rwxp-DaARWcCos:------:allow
group@:rwxp-DaARWc--s:------:allow
everyone@:rwxp-DaARWc--s:------:allow
drwxrwsrwx+ 2 henson csupomona 2 Feb 19 12:56 testdir/two
everyone@:rwxpdDaARWcCos:fd----:allow

$ grep chmod /tmp/truss.out

chmod("testdir/three", 02777) = 0
chmod("testdir/three", 02777) = 0

chmod breaks the ACL. If you do "cp -rp", it still chmod's it, but then restores the original ACL:

$ truss cp rp testdir/two testdir/three 2>/tmp/truss2.out
$ ls -Vd testdir/three
drwxrwsrwx+ 2 henson csupomona 2 Feb 19 12:56 testdir/three
everyone@:rwxpdDaARWcCos:fd---
:allow

$ egrep 'chmod|acl' /tmp/truss2.out

acl("testdir/two", ACE_GETACLCNT, 0, 0x00000000) = 1
acl("testdir/two", ACE_GETACL, 1, 0x08067100) = 1
chmod("testdir/three", 02777) = 0
chmod("testdir/three", 042777) = 0
acl("testdir/three", ACE_SETACL, 1, 0x08067118) = 0

I don't use nautilus or explorer, but I assume they do the same thing. There's nothing wrong with zfs or the inherited ACL's, it's just userland commands doing stupid stuff (or at least out of date stuff that's really no longer a good thing to do in a world of ACL's).

You can see the calls to chmod in lib/libcmd/common/cp.c in the source code. The code is a little, well, let's just call it convoluted, so I didn't take the time to try to understand why it is calling chmod or see if there was an easy way to make it not. You could open a new issue such as "cp shouldn't call chmod" or "cp should be ACL-aware", I might take a look at it someday if I have the time. That still wouldn't fix nautilus or explorer though.

If you have a recent enough illumos, you could try setting aclmode=restricted, which will prevent chmod from breaking the ACL, at the cost of chmod returning an error code, which may or may not work out for you. Someday I'm going to try to push through aclmode=ignore, which will also prevent chmod from breaking an ACL, but just turn it into an ignored no-op rather than returning an error, which might be useful in this situation.

#5

Updated by Richard PALO over 7 years ago

Interesting.

From the ZFS manpage :

aclinherit=discard | noallow | restricted | passthrough |
     passthrough-x

         Controls how ACL entries are inherited  when  files  and
         directories   are   created. A  file  system  with  an
         aclinherit property of discard does not inherit any  ACL
         entries. A file system with an aclinherit property value
         of noallow only inherits inheritable  ACL  entries  that
         specify  "deny"  permissions.  The  property  value res-
         tricted  (the  default)  removes   the   write_acl   and
         write_owner permissions when the ACL entry is inherited.
         A file system  with  an  aclinherit  property  value  of
         passthrough inherits all inheritable ACL entries without
         any modifications made to the ACL entries when they  are
         inherited.  A  file  system  with an aclinherit property
         value  of  passthrough-x  has  the   same   meaning   as
         passthrough,  except that the owner@, group@, and every-
         one@ ACEs inherit the execute  permission  only  if  the
         file creation mode also requests the execute bit.

         When the property value is set to passthrough, files are
         created  with a mode determined by the inheritable ACEs.
         If no inheritable ACEs exist that affect the mode,  then
         the mode is set in accordance to the requested mode from
         the application

I'm running oi_151a7, I don't believe much is altered in this case.

I guess I don't understand why restricted should work.

After setting aclinherit=restricted, the following occurs (I believe as expected):

richard@x3200:~/testacl$ mkdir foo
richard@x3200:~/testacl$ chmod A=everyone@:rwxpdDaARWcCos:fd:allow foo/
richard@x3200:~/testacl$ ls -ladV foo/
drwxrwxrwx+  2 richard  staff          2 févr. 20 07:11 foo//
              everyone@:rwxpdDaARWcCos:fd-----:allow
richard@x3200:~/testacl$ mkdir foo/bar
richard@x3200:~/testacl$ ls -laV foo/
total 9
drwxrwxrwx+  3 richard  staff          3 févr. 20 07:12 ./
              everyone@:rwxpdDaARWcCos:fd-----:allow
drwxrwxrwx+  3 richard  staff          3 févr. 20 07:11 ../
              everyone@:rwxpdDaARWcCos:fd-----:allow
drwxr-xr-x   2 richard  staff          2 févr. 20 07:12 bar/
                 owner@:rwxp--aARWcCos:-------:allow
                 group@:r-x---a-R-c--s:-------:allow
              everyone@:r-x---a-R-c--s:-------:allow

Therefore, I believe in my use case 'passthrough' seems appropriate.

I thought after your observations to try /usr/xpg4/bin/cp, but noticed the same.

I was startled to notice that /usr/gnu/bin/cp worked as expected.
Attached is the gnu-cp truss output, which does not do any chmods..

In summary, you're right about cp (/usr/bin and /usr/xpg4/bin) needing upgrading.

I look into how nautilus file-operations do things...

I'll have too leave it a knowledgeable CIFS server pro to check for "explorer".

#6

Updated by Paul Henson over 7 years ago

I said aclmode=restricted, not aclinherit=restricted, you should leave aclinherit set to passthrough. I don't think OI has aclmode=restricted yet, it just got pushed into upstream illumos a few months ago.

By "explorer" you meant Windows explorer accessing the filesystem via CIFS? Are you using the in-kernel CIFS server or samba to provide CIFS service? If the former, that bypasses the POSIX layer so you shouldn't have any ACL issues caused by the illumos/zfs side.

#7

Updated by Richard PALO over 7 years ago

Paul Henson wrote:

I said aclmode=restricted, not aclinherit=restricted, you should leave aclinherit set to passthrough. I don't think OI has aclmode=restricted yet, it just got pushed into upstream illumos a few months ago.

on oi_151a7, man zfs talks about aclmode=discard | groupmask | passthrough
so I'll have to wait to test that...

By "explorer" you meant Windows explorer accessing the filesystem via CIFS? Are you using the in-kernel CIFS server or samba to provide CIFS service? If the former, that bypasses the POSIX layer so you shouldn't have any ACL issues caused by the illumos/zfs side.

it appears the windows explorer sessions are those that populate the initial directories prior to copy, which is done primarily with nautilus - locally, for the most part (using VNC).
I'll recheck myself to make sure when I get a chance to offend one of the techniciens M$Win laptops.

#8

Updated by Richard PALO over 7 years ago

Had a chance to onu to a recent illumos gate, so I thought I'd try 'aclmode=restricted'.
Seems to have done the trick:


richard@x3200:~$ zfs get aclmode,aclinherit,xattr dpool/export/home/richard
NAME                       PROPERTY    VALUE          SOURCE
dpool/export/home/richard  aclmode     restricted     local
dpool/export/home/richard  aclinherit  passthrough    local
dpool/export/home/richard  xattr       on             default
richard@x3200:~$ /usr/bin/mkdir testacl
richard@x3200:~$ /usr/bin/chmod A=everyone@:rwxpdDaARWcCos:fd-----:allow testacl
richard@x3200:~$ mkdir testacl/foo
richard@x3200:~$ touch testacl/foo/foo.txt
richard@x3200:~$ /usr/bin/ls -laV -/c testacl/ testacl/foo/
testacl/:
total 75
drwxrwxrwx+  3 richard  staff          3 mars  6 08:18 .
        {A------m----}
              everyone@:rwxpdDaARWcCos:fd-----:allow
drwxrwxrwx  88 richard  staff        295 mars  6 08:18 ..
        {A------m----}
                 owner@:rwxp--aARWcCos:-------:allow
                 group@:rwxp--a-R-c--s:-------:allow
              everyone@:rwxp--a-R-c--s:-------:allow
drwxrwxrwx+  2 richard  staff          3 mars  6 08:18 foo
        {A------m----}
              everyone@:rwxpdDaARWcCos:fd----I:allow

testacl/foo/:
total 7
drwxrwxrwx+  2 richard  staff          3 mars  6 08:18 .
        {A------m----}
              everyone@:rwxpdDaARWcCos:fd----I:allow
drwxrwxrwx+  3 richard  staff          3 mars  6 08:18 ..
        {A------m----}
              everyone@:rwxpdDaARWcCos:fd-----:allow
-rwxrwxrwx+  1 richard  staff          0 mars  6 08:18 foo.txt
        {A------m----}
              everyone@:rwxpdDaARWcCos:------I:allow
richard@x3200:~$ mkdir testacl/bar
richard@x3200:~$ /usr/bin/cp testacl/foo/foo.txt testacl/bar/
richard@x3200:~$ /usr/bin/cp -R testacl/foo testacl/foobar
richard@x3200:~$ /usr/bin/ls -laV -/c testacl/ testacl/*bar
testacl/:
total 81
drwxrwxrwx+  5 richard  staff          5 mars  6 08:22 .
        {A------m----}
              everyone@:rwxpdDaARWcCos:fd-----:allow
drwxrwxrwx  88 richard  staff        295 mars  6 08:18 ..
        {A------m----}
                 owner@:rwxp--aARWcCos:-------:allow
                 group@:rwxp--a-R-c--s:-------:allow
              everyone@:rwxp--a-R-c--s:-------:allow
drwxrwxrwx+  2 richard  staff          3 mars  6 08:21 bar
        {A------m----}
              everyone@:rwxpdDaARWcCos:fd----I:allow
drwxrwxrwx+  2 richard  staff          3 mars  6 08:18 foo
        {A------m----}
              everyone@:rwxpdDaARWcCos:fd----I:allow
drwxrwxrwx+  2 richard  staff          3 mars  6 08:22 foobar
        {A------m----}
              everyone@:rwxpdDaARWcCos:fd----I:allow

testacl/bar:
total 7
drwxrwxrwx+  2 richard  staff          3 mars  6 08:21 .
        {A------m----}
              everyone@:rwxpdDaARWcCos:fd----I:allow
drwxrwxrwx+  5 richard  staff          5 mars  6 08:22 ..
        {A------m----}
              everyone@:rwxpdDaARWcCos:fd-----:allow
-rwxrwxrwx+  1 richard  staff          0 mars  6 08:21 foo.txt
        {A------m----}
              everyone@:rwxpdDaARWcCos:------I:allow

testacl/foobar:
total 7
drwxrwxrwx+  2 richard  staff          3 mars  6 08:22 .
        {A------m----}
              everyone@:rwxpdDaARWcCos:fd----I:allow
drwxrwxrwx+  5 richard  staff          5 mars  6 08:22 ..
        {A------m----}
              everyone@:rwxpdDaARWcCos:fd-----:allow
-rwxrwxrwx+  1 richard  staff          0 mars  6 08:22 foo.txt
        {A------m----}
              everyone@:rwxpdDaARWcCos:------I:allow

I did take a look in usr/src/lib/libcmd/common/cp.c and it is not at all clear to me by inspection if the chmods (lines 319 & 638) are duly correct... shouldn't there be some consideration for inherited permissions, even in an non ZFS filesystem?
What is nice in this case is the "protection" offered by this recommended mode (perhaps useful to add to the ZFS Best Practices Guide.
cheers

#9

Updated by Yuri Pankov over 3 years ago

  • Status changed from New to Feedback
  • Assignee set to Richard PALO

(sorry, TL;DR) I've upstreamed some of our ACL related changes last year, could you check that the problem is still present?

Also available in: Atom PDF