Bug 9124 - Samba fails to set "inherited" bit on inherited ACE's.
Summary: Samba fails to set "inherited" bit on inherited ACE's.
Status: RESOLVED FIXED
Alias: None
Product: Samba 3.6
Classification: Unclassified
Component: File services (show other bugs)
Version: unspecified
Hardware: All All
: P5 normal
Target Milestone: ---
Assignee: Karolin Seeger
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-08-28 17:30 UTC by Jeremy Allison
Modified: 2020-11-02 12:58 UTC (History)
0 users

See Also:


Attachments
git-am fix for 3.6.next (13.12 KB, patch)
2012-08-30 00:05 UTC, Jeremy Allison
jra: review+
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jeremy Allison 2012-08-28 17:30:20 UTC
Reported by "Walkes, Dan" <dwalkes@tandbergdata.com>.

I've noticed a problem with Debian wheezy + samba 3.6.6 configured with
acl_xattr.  The following test sequence causes Windows Explorer to
report incorrectly ordered permission entries:
1)      Map a share as with "admin" user credentials  to a drive letter
on a Windows client
2)      Create a folder at the root of the share "rootfolder"
3)      Create a subfolder "subfolder1" under "rootfolder"
4)      Un-check "Include inheritable permissions from this object's
parent" in the windows security settings dialog for Windows Explorer on
the root folder
5)      Create a subfolder "subfolder2" under "subfolder1"
6)      Right-click with Windows Explorer and attempt to edit the
permissions of "subfolder2".  Windows Explorer pops up a message stating
"The permissions on subfolder2 are incorrectly ordered, which may cause
some entries to be ineffective."

This is reproducible on every Windows client system I've tried including
Windows 7, XP, Server 2008 R2 and Server 2003.
When incorrectly ordered, the permissions look like this as printed by
smbcacls smbcacls //localhost/20120821_3
rootfolder/subfolder1/subfolder2
REVISION:1
CONTROL:0x8004
OWNER:BIZNAS-H5\admin
GROUP:BIZNAS-H5\None
ACL:BIZNAS-H5\admin:ALLOWED/0x0/RWXDPO
ACL:Creator Owner:ALLOWED/OI|CI|IO|I/RWXDPO
ACL:BIZNAS-H5\None:ALLOWED/0x0/RWXDPO
ACL:Creator Group:ALLOWED/OI|CI|IO|I/RWXDPO
ACL:Everyone:ALLOWED/OI|CI|I/RWXDPO

For comparison, here is the same subfolder tree without performing step
4 above to un-check the "Include inheritable perimssions" box from
Windows explorer:
smbcacls //localhost/20120821_3 rootfolder/subfolder1/subfolder2
REVISION:1
CONTROL:0x8004
OWNER:BIZNAS-H5\admin
GROUP:BIZNAS-H5\None
ACL:BIZNAS-H5\admin:ALLOWED/0x0/RWXDPO
ACL:Creator Owner:ALLOWED/OI|CI|IO/RWXDPO
ACL:BIZNAS-H5\None:ALLOWED/0x0/RWXDPO
ACL:Creator Group:ALLOWED/OI|CI|IO/RWXDPO
ACL:Everyone:ALLOWED/OI|CI/RWXDPO admin@BizNAS-H5:/mnt/lvol0$

Note that the ACE entries are in the same order, however in the first
case where Windows reports incorrectly ordered ACE's Creator Owner,
Creator Group and Everyone ACE's include the "I" flag
SEC_ACE_FLAG_INHERITED_ACE
The share folder, rootfolder and subfolder1 permissions are as shown
below (steps 1 through 3)

smbcacls //localhost/20120821_3 rootfolder/..
REVISION:1
CONTROL:0x8004
OWNER:BIZNAS-H5\nobody
GROUP:Unix Group\root
ACL:BIZNAS-H5\nobody:ALLOWED/0x0/FULL
ACL:Unix Group\%naslocal%:ALLOWED/0x0/FULL ACL:Unix
Group\root:ALLOWED/0x0/FULL ACL:BIZNAS-H5\admin:ALLOWED/0x0/FULL
ACL:Everyone:ALLOWED/0x0/
ACL:Creator Owner:ALLOWED/OI|CI|IO/RWXDPO ACL:Creator
Group:ALLOWED/OI|CI|IO/RWXDPO ACL:Everyone:ALLOWED/OI|CI|IO/RWXDPO

smbcacls //localhost/20120821_3 rootfolder
REVISION:1
CONTROL:0x8004
OWNER:BIZNAS-H5\admin
GROUP:BIZNAS-H5\None
ACL:BIZNAS-H5\admin:ALLOWED/0x0/RWXDPO
ACL:Creator Owner:ALLOWED/OI|CI|IO/RWXDPO
ACL:BIZNAS-H5\None:ALLOWED/0x0/RWXDPO
ACL:Creator Group:ALLOWED/OI|CI|IO/RWXDPO
ACL:Everyone:ALLOWED/OI|CI/RWXDPO admin@BizNAS-H5:/mnt/lvol0$

smbcacls //localhost/20120821_3 rootfolder/subfolder1
REVISION:1
CONTROL:0x8004
OWNER:BIZNAS-H5\admin
GROUP:BIZNAS-H5\None
ACL:BIZNAS-H5\admin:ALLOWED/0x0/RWXDPO
ACL:Creator Owner:ALLOWED/OI|CI|IO/RWXDPO
ACL:BIZNAS-H5\None:ALLOWED/0x0/RWXDPO
ACL:Creator Group:ALLOWED/OI|CI|IO/RWXDPO
ACL:Everyone:ALLOWED/OI|CI/RWXDPO

Note that in each case flags OI|CI|IO are set on Creator Owner, Creator
Group and Everyone ACE's, however corresponding subfolders do not have
the "I" flag and SEC_ACE_FLAG_INHERITED_ACE set.  I would have expected
this to be set for each inherited permission.  Indeed Windows explorer
does mark these permissions as "Inherited From Z:\" where Z:\ is the
mapped share folder.

The value of subfolder1 after step 4 is:

smbcacls //localhost/20120821_3 rootfolder/subfolder1
REVISION:1
CONTROL:0x8d04
OWNER:BIZNAS-H5\admin
GROUP:BIZNAS-H5\None
ACL:BIZNAS-H5\admin:ALLOWED/I/RWXDPO
ACL:Creator Owner:ALLOWED/OI|CI|IO|I/RWXDPO
ACL:BIZNAS-H5\None:ALLOWED/I/RWXDPO
ACL:Creator Group:ALLOWED/OI|CI|IO|I/RWXDPO
ACL:Everyone:ALLOWED/OI|CI|I/RWXDPO

Note that when un-checking "Include inheritable permissions" and adding
existing permissions using Windows Explorer, Windows forces the "I"
SEC_ACE_FLAG_INHERITED_ACE flag on subfolder1 (and all subdirectories
below rootfolder) ACE's including the ACE entries "admin" and "None"
which were actually not inherited but created through the "Creator
Owner" ACE.

When viewing "Advanced Security Settings" on a folder with incorrectly
ordered permissions, Windows provides a "reorder" option.  Reordering
the ACE's results in the following permissions:

smbcacls //localhost/20120821_3 rootfolder/subfolder1/subfolder2
REVISION:1
CONTROL:0x8d04
OWNER:BIZNAS-H5\admin
GROUP:BIZNAS-H5\None
ACL:BIZNAS-H5\admin:ALLOWED/0x0/RWXDPO
ACL:BIZNAS-H5\None:ALLOWED/0x0/RWXDPO
ACL:BIZNAS-H5\admin:ALLOWED/I/RWXDPO
ACL:Creator Owner:ALLOWED/OI|CI|IO|I/RWXDPO
ACL:BIZNAS-H5\None:ALLOWED/I/RWXDPO
ACL:Creator Group:ALLOWED/OI|CI|IO|I/RWXDPO
ACL:Everyone:ALLOWED/OI|CI|I/RWXDPO

Note that all "I" SEC_ACE_FLAG_INHERITED_ACE's are listed below entries
with inherit flags cleared - I'm guessing this was the reason for the
incorrect ordering message in Windows.  I'm not sure why this is
required by Windows and I haven't come up with a scenario where
permissions are actually ineffective due to this ordering.

Assuming it is a requirement to order permissions in this way, I think
I've noticed two problems which are either samba bugs or some other
problem with my configuration which I've not yet identified.
 1) ACE's are not ordered based in SEC_ACE_FLAG_INHERITED_ACE's to
include all permissions with "I" values at the end of the ACE list.
 2) Although permissions on folders are marked with OI|CI|IO flags
appear to inherit properly from Windows, the "I" flag is not set in
corresponding ACE's.
My smb.conf configuration is below.  I haven't found anything in the man
page for smb.conf which would explain this behavior.  I've experimented
with turning off vfs_acl_xattr with this change to smb.conf:
#       vfs objects = acl_xattr
        dos filemode = yes
        inherit acls = yes
        force unknown acl user = yes
However in this case I've noticed that Windows does not indicate
permissions are inherited ("Include inheritable permissions from this
object's parent is un-checked") and I'd prefer a configuration which
mimics Windows server implementation as closely as possible.

Full smb.conf configuration:
[global]
        workgroup = WORKGROUP
        security = user
        server string = %h server
        obey pam restrictions = Yes
        pam password change = Yes
        unix password sync = Yes
        log level = 0
        syslog = 0
        log file = /var/log/samba/log.%m
        max log size = 1000
        local master = No
        domain master = No
        dns proxy = No
        socket options = TCP_NODELAY
        panic action = /usr/share/samba/panic-action %d
        idmap alloc config: range = 10000-100000
        idmap uid = 10000 - 100000
        idmap gid = 10000 - 100000
        template shell = /bin/bash
        winbind enum users = Yes
        winbind enum groups = Yes
        winbind use default domain = No
        winbind refresh tickets = Yes
        store dos attributes =  yes
        ea support = yes
        vfs objects = acl_xattr
        passdb backend = tdbsam
        username map = /etc/samba/smbusers
        encrypt passwords = yes
        map to guest = Bad User
        deadtime = 5
        include = /etc/samba/dhcp.conf

[20120821_3]
        comment =
        path = /tmp/testshare3
        map acl inherit = Yes
        map archive = No
        map read only = No
        security mask = 0777
        create mask = 0640
        directory mask = 0750
        delete readonly = yes
        directory mode= 0777
        create mode= 0777
        acl map full control = True
        read only = Yes
        invalid users =
        valid users = "@%naslocal%" "admin"
        read list =
        write list = "@%naslocal%" "admin"
Comment 1 Jeremy Allison 2012-08-30 00:05:54 UTC
Created attachment 7848 [details]
git-am fix for 3.6.next

Patchset that fixes our use of the inherited bits in ACLs. Back port of code that has gone into master. We now pass the raw.acl and smb2.acls tests from smbtorture4.

Jeremy.
Comment 2 Richard Sharpe 2012-08-30 19:31:27 UTC
Comment on attachment 7848 [details]
git-am fix for 3.6.next

OK, this looks good.
Comment 3 Richard Sharpe 2012-08-30 19:31:57 UTC
Approved.
Comment 4 Jeremy Allison 2012-08-30 19:52:53 UTC
Comment on attachment 7848 [details]
git-am fix for 3.6.next

Richard approved this in the comments below.
Comment 5 Jeremy Allison 2012-08-30 19:53:17 UTC
Re-assigning to Karolin for inclusion in 3.6.next.
Jeremy.
Comment 6 Karolin Seeger 2012-08-31 06:47:50 UTC
Pushed to v3-6-test.
Closing out bug report.

Thanks!
Comment 7 Paul 2020-11-02 12:58:07 UTC
I'm using smbcacls (Version 4.9.5-Debian) on my Debian test server to add permisions for AD users to shares on Windows Server 2012r2.

1. Created a new dir named ctest without any ACL modifications

result of smbcacls //X.X.X.X/home /ctest -U user -W PUW -m SMB2:

REVISION:1
CONTROL:SR|DI|DP
OWNER:BUILTIN\Administrators
GROUP:PUW\Domain Users
ACL:BUILTIN\Administrators:ALLOWED/I/FULL
ACL:CREATOR OWNER:ALLOWED/OI|CI|IO|I/FULL
ACL:PUW\Gr_Administratorzy_Merkury:ALLOWED/OI|CI|I/FULL
ACL:NT AUTHORITY\SYSTEM:ALLOWED/OI|CI|I/FULL
ACL:BUILTIN\Administrators:ALLOWED/OI|CI|IO|I/FULL

result of smbcacls //X.X.X.X/home /ctest -U user -W PUW -m SMB2 --sddl:

O:BAG:DUD:AI(A;ID;0x001f01ff;;;BA)(A;OICIIOID;0x001f01ff;;;CO)(A;OICIID;0x001f01ff;;;S-1-5-21-72573241-492726023-1721331951-1135)(A;OICIID;0x001f01ff;;;SY)(A;OICIIOID;0x001f01ff;;;BA)

CONTROL has DI, and SDDL has AI.

2. Add another ACL like so smbcacls //X.X.X.X/home /ctest -U user -W PUW -m SMB2 -a 'ACL:PUW\pszajna:ALLOWED/3/FULL'

result of smbcacls //X.X.X.X/home /ctest -U user -W PUW -m SMB2:

REVISION:1
CONTROL:SR|DP
OWNER:BUILTIN\Administrators
GROUP:PUW\Domain Users
ACL:PUW\pszajna:ALLOWED/OI|CI/FULL
ACL:BUILTIN\Administrators:ALLOWED/I/FULL
ACL:CREATOR OWNER:ALLOWED/OI|CI|IO|I/FULL
ACL:PUW\Gr_Administratorzy_Merkury:ALLOWED/OI|CI|I/FULL
ACL:NT AUTHORITY\SYSTEM:ALLOWED/OI|CI|I/FULL
ACL:BUILTIN\Administrators:ALLOWED/OI|CI|IO|I/FULL

DI in CONTROL is lost.

result of smbcacls //X.X.X.X/home /ctest -U user -W PUW -m SMB2 --sddl:

O:BAG:DUD:(A;OICI;0x001f01ff;;;S-1-5-21-72573241-492726023-1721331951-1175)(A;ID;0x001f01ff;;;BA)(A;OICIIOID;0x001f01ff;;;CO)(A;OICIID;0x001f01ff;;;S-1-5-21-72573241-492726023-1721331951-1135)(A;OICIID;0x001f01ff;;;SY)(A;OICIIOID;0x001f01ff;;;BA)

AI in SDDL is lost.

I've even tested setting the exact same SDDL (without adding any ACL) as at the beginning where permissions were ok like so:

smbcacls //10.10.50.23/home /ctest -U ldap -W PUW -m SMB2 --sddl -S "O:BAG:DUD:AI(A;ID;0x001f01ff;;;BA)(A;OICIIOID;0x001f01ff;;;CO)(A;OICIID;0x001f01ff;;;S-1-5-21-72573241-492726023-1721331951-1135)(A;OICIID;0x001f01ff;;;SY)(A;OICIIOID;0x001f01ff;;;BA)"

result of smbcacls //X.X.X.X/home /ctest -U user -W PUW -m SMB2:

REVISION:1
CONTROL:SR|DP
OWNER:BUILTIN\Administrators
GROUP:PUW\Domain Users
ACL:BUILTIN\Administrators:ALLOWED/I/FULL
ACL:CREATOR OWNER:ALLOWED/OI|CI|IO|I/FULL
ACL:PUW\Gr_Administratorzy_Merkury:ALLOWED/OI|CI|I/FULL
ACL:NT AUTHORITY\SYSTEM:ALLOWED/OI|CI|I/FULL
ACL:BUILTIN\Administrators:ALLOWED/OI|CI|IO|I/FULL

DI in CONTROL is lost.

result of smbcacls //X.X.X.X/home /ctest -U user -W PUW -m SMB2 --sddl:

O:BAG:DUD:(A;ID;0x001f01ff;;;BA)(A;OICIIOID;0x001f01ff;;;CO)(A;OICIID;0x001f01ff;;;S-1-5-21-72573241-492726023-1721331951-1135)(A;OICIID;0x001f01ff;;;SY)(A;OICIIOID;0x001f01ff;;;BA)

AI in SDDL is lost.

3. Creating subfolder inside ctest causes Windows yeling "Wrong permissions order" and asks for Reodering.

result of smbcacls //X.X.X.X/home /ctest/test -U user -W PUW -m SMB2:

REVISION:1
CONTROL:SR|DP
OWNER:BUILTIN\Administrators
GROUP:PUW\Domain Users
ACL:BUILTIN\Administrators:ALLOWED/0x0/FULL
ACL:CREATOR OWNER:ALLOWED/OI|CI|IO|I/FULL
ACL:PUW\Gr_Administratorzy_Merkury:ALLOWED/OI|CI/FULL
ACL:NT AUTHORITY\SYSTEM:ALLOWED/OI|CI/FULL
ACL:BUILTIN\Administrators:ALLOWED/OI|CI/FULL

I flag is lost in some ACL's.