Permissions incorrectly ordered on Windows after disabling inheritance
Richard Sharpe
realrichardsharpe at gmail.com
Sun Aug 26 16:52:05 MDT 2012
On Sun, Aug 26, 2012 at 3:21 PM, Andrew Bartlett <abartlet at samba.org> wrote:
> 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
Once I get a capture I can look at the problem, and then try to add a
unit test for this case to ntacls.py
--
Regards,
Richard Sharpe
(何以解憂?唯有杜康。--曹操)
More information about the samba-technical
mailing list