[Samba] Permissions incorrectly ordered on Windows after disabling inheritance

Walkes, Dan dwalkes at tandbergdata.com
Thu Aug 30 17:09:10 MDT 2012


On Wed, Aug 29, 2012 at 21:45:24, Jeremy Allison wrote:
> On Fri, Aug 24, 2012 at 11:08:53AM -0600, Walkes, Dan wrote:
> > Hi everyone,
> >
> > I've noticed a problem with Debian wheezy + samba 3.6.6 configured 
> > with acl_xattr in my configuration.  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."
> 
> FYI, the complete and correct fix for this ifor 3.6.next s now
attached to bug :
> 
> https://bugzilla.samba.org/show_bug.cgi?id=9124
> 
> as a patch. Please test (it fixes the problem here). Thanks for 
> reporting this, the same code will go into master as soon as I've 
> finished wrestling with autobuild :-).
> 

Thanks Jeremy.  I've tested today.  I can confirm it fixes the incorrect
ordering issue and sequence 1-6 works for me.  I can also confirm that
after removing inheritance on a root folder from windows the I flag is
set for all permissions on subfolders as expected.  I did notice however
that in my case if I never modify permissions or change permissions from
Windows Explorer the I flag is still not set on inherited permissions,
at least with my configuration. 

For instance if my share folder permissions are: 

smbcacls --user=K9\\tandberg //localhost/20120830_4 rootfolder/..
REVISION:1
CONTROL:0x8004
OWNER:BIZNAS-B2\nobody
GROUP:Unix Group\root
ACL:BIZNAS-B2\nobody:ALLOWED/0x0/FULL
ACL:K9\domain users:ALLOWED/0x0/FULL
ACL:Unix Group\%naslocal%:ALLOWED/0x0/FULL
ACL:Unix Group\root:ALLOWED/0x0/FULL
ACL:BIZNAS-B2\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

Each of my subfolders have permissions which look like this:

smbcacls --user=K9\\tandberg //localhost/20120830_4 rootfolder
REVISION:1
CONTROL:0x8004
OWNER:BIZNAS-B2\admin
GROUP:BIZNAS-B2\None
ACL:BIZNAS-B2\admin:ALLOWED/0x0/RWXDPO
ACL:Creator Owner:ALLOWED/OI|CI|IO/RWXDPO
ACL:BIZNAS-B2\None:ALLOWED/0x0/RWXDPO
ACL:Creator Group:ALLOWED/OI|CI|IO/RWXDPO
ACL:Everyone:ALLOWED/OI|CI/RWXDPO

I would have expected the I flag to be set on Creator Owner, Creator
Group and Everyone in this case since these permissions were inherited
from the share folder.  This is what I see with a Windows 7 file share.

However, after I modify permissions on any folder in any way from
windows explorer (even if I don't modify Creator Owner, Creator Group or
Everyone), all inherited permissions on subfolders have the I flag set.
This applies both to subfolders which existed before the change and for
new subfolders created after I made the change from Windows Explorer.  I
don't see this behavior if I change from smbcacls, only if I change from
Windows Explorer.  If I use Windows Explorer to modify the permissions
on the root folder in any way, all inherited permissions have the I flag
set on all subfolders as I would expect.

I'm not sure that missing the I flag is actually important as long as
the permissions are inheriting and now that windows is no longer
complaining about ordering.  I just thought I would bring it up here in
case it was related and in case you thought it was important.  I can
gather more data if you are interested... let me know

Thanks again!
Dan

> Cheers,
> 
> 	Jeremy.




More information about the samba mailing list