Bug 8857 - Setting traverse rights fails to enable directory traversal when acl_xattr in use
Summary: Setting traverse rights fails to enable directory traversal when acl_xattr in...
Alias: None
Product: Samba 3.6
Classification: Unclassified
Component: VFS Modules (show other bugs)
Version: 3.6.4
Hardware: x86 All
: P5 normal
Target Milestone: ---
Assignee: Karolin Seeger
QA Contact: Samba QA Contact
Depends on:
Reported: 2012-04-12 02:04 UTC by John Mulligan (dead mail address)
Modified: 2012-05-07 16:37 UTC (History)
0 users

See Also:
rsharpe: review+

logs and sample configs (736.59 KB, application/zip)
2012-04-13 00:06 UTC, John Mulligan (dead mail address)
no flags Details
git-am patch for v3-6-test (3.12 KB, patch)
2012-04-17 01:21 UTC, Jeremy Allison
jra: review+

Note You need to log in before you can comment on or make changes to this bug.
Description John Mulligan (dead mail address) 2012-04-12 02:04:21 UTC
I've hit this issue with versions 3.6.4, 3.6.3, and 3.5.12, running on Linux. The 3.6 versions I've compiled myself from source.

Tested with Windows 7 and Windows Server 2008 acting as clients.

If I have a directory structure like:  share/a/b/c/dest

Where I have effective rx permissions on share, x permissions on a, b and c and rwx permissions on dest, I can not access dest if I have acl_xattr enabled - even if I manually type the path in explorer or cmd.exe. I've tried setting the other-execute bit via the command line and creating an ACE through windows with the Traverse permission set, both had the same behavior.

If I disable acl_xattr I am able to "chdir" into the dest directory but not any of the a/b/c directories as I would expect. 

When I tried this test with smbclient I was able to cd to the dest directory and access the files within - regardless of having the vfs module enabled or not.
In addition (and this is a bit strange) if I enable SMB2 protocol on 3.6.x and try and access the directory through windows it also works as expected. In other words:

| acl_xattr vfs | SMB2 | Traverse Works
|    no         | no   | Yes
|    yes        | no   | No
|    yes        | yes  | Yes

My (names changed to protect the innocent) smb.conf normally looks like:

        workgroup = EXAMPLE2
        realm = EXAMPLE2.MYCORP.NET
        security = ADS
        allow trusted domains = No
        syslog = 0
        unix extensions = No
        load printers = No
        printcap name = /dev/null
        disable spoolss = Yes
        show add printer wizard = No
        winbind enum users = Yes
        winbind enum groups = Yes
        idmap config EXAMPLE2: range = 400000-8000000
        idmap config EXAMPLE2: backend = rid
        idmap config *: range = 200000-210000
        idmap config *: backend = tdb
        force unknown acl user = Yes

[Example Share]
        path = /mnt/foo
        read only = No
        inherit permissions = Yes
        inherit acls = Yes
        map acl inherit = Yes
        hide unreadable = Yes
        veto files = /.private/
        store dos attributes = Yes
        delete readonly = Yes
        dos filemode = Yes
        vfs objects = acl_xattr

Using acl_xattr is pretty vital for me, because our users expect a better representation of the NTFS style ACLs than going without the vfs module provides. Please let me know if there is any additional information I can provide to help debug this issue.
Thank You.
Comment 1 Jeremy Allison 2012-04-12 04:03:46 UTC
Can you attach a debug level 10 from a client failing to access (using SMB1) and a second (separate) debug level 10 from a client succeeding the access (using SMB2) so I can compare ?

Thanks !

Comment 2 John Mulligan (dead mail address) 2012-04-13 00:06:15 UTC
Created attachment 7451 [details]
logs and sample configs

These are lightly anonymized logs. I hope it helps.
Comment 3 John Mulligan (dead mail address) 2012-04-16 01:42:37 UTC
Is there anything else I can provide to help fix this issue? I was wondering if you had any thoughts about how difficult this may be to resolve. Anything I could communicate to our users would be extremely handy, thank you for your help.
Comment 4 Jeremy Allison 2012-04-17 01:21:22 UTC
Created attachment 7457 [details]
git-am patch for v3-6-test

This has been fixed a different way in master, but this should work for 3.6.x.

The problem is we were checking the incorrect ACL on a directory open for list - we were checking the parent, not the directory itself.

This explains perfectly why it works in SMB2 but not SMB1, as in SMB2 directory listings are done against an already existing file handle, not a pathname.

Let me know if this fixes it for you.

Comment 5 John Mulligan (dead mail address) 2012-04-17 23:08:20 UTC
Yes, that seems to have done the trick. Thank you so much for your help!

Would you like me to update the bug status?
Comment 6 Jeremy Allison 2012-04-17 23:10:16 UTC
No, I'll get Richard Sharpe on the Team to review and if he's happy we'll add to 3.6.next.
Comment 7 Jeremy Allison 2012-04-17 23:10:36 UTC
Comment on attachment 7457 [details]
git-am patch for v3-6-test

Richard, please review for 3.6.next.
Comment 8 Richard Sharpe 2012-04-21 22:14:58 UTC
OK, I have reviewed it, and it seems good to me.
Comment 9 Jeremy Allison 2012-04-21 22:58:11 UTC
Comment on attachment 7457 [details]
git-am patch for v3-6-test

Richard, I'm setting the '?' flag to '+' for you - but is there a reason this doesn't work for you on bugzilla ?

Comment 10 Jeremy Allison 2012-04-21 22:58:33 UTC
Re-assigning to Karolin for inclusion in 3.6.next.

Comment 11 Richard Sharpe 2012-04-29 17:29:04 UTC
(In reply to comment #9)
> Comment on attachment 7457 [details]
> git-am patch for v3-6-test
> Richard, I'm setting the '?' flag to '+' for you - but is there a reason this
> doesn't work for you on bugzilla ?
> Jeremy.

I can't understand it. The review stuff never shows up for me. Perhaps it is because my user-name is actually realrichardsharpe@gmail.com.

Can someone change it to remove the gmail.com? Or can I use admin to do that?
Comment 12 Karolin Seeger 2012-05-07 16:37:15 UTC
Pushed to v3-6-test.
Closing out bug report.