Permissions incorrectly ordered on Windows after disabling inheritance

Andrew Bartlett abartlet at samba.org
Sun Aug 26 16:21:12 MDT 2012


On Sun, 2012-08-26 at 10:51 -0700, Richard Sharpe wrote:
> On Sun, Aug 26, 2012 at 9:28 AM, Walkes, Dan <dwalkes at tandbergdata.com> wrote:
> > Hi everyone,
> >
> > I'm reposting this message from the samba-general list based on
> > suggestions from members of that list.
> >
> > 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 at 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 at 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.

> > If anyone has suggestions about any further troubleshooting steps to try
> > or changes in configuration which may resolve this issue please let me
> > know.  Also if logs for any portion of this sequence would be useful I
> > can collect them.
> 
> I have seen similar problems to this before, in the 3.5.x vfs_acl_xattr stuff.
> 
> Can you get a packet capture of the step where it all goes wrong? It
> would be useful to see the ordering of the ACEs in the SD that is
> being set and to see if acl_xattr is adding additional ACEs in the
> wrong order.

Richard and Dan,

It would be really, really useful to get this into a unit test.  I've
created a scheme that will allow this locally in: 
source4/scripting/python/samba/tests/ntacls.py 

Otherwise or in addition we should add a remote test in smbtorture.  The
new test environment work I did recently should help prevent us from
regressing here.

Andrew Bartlett
-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org




More information about the samba-technical mailing list