After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 752067 - smb backend does not support ACL
smb backend does not support ACL
Status: RESOLVED NOTGNOME
Product: gvfs
Classification: Core
Component: smb backend
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gvfs-maint
gvfs-maint
Depends on:
Blocks:
 
 
Reported: 2015-07-07 12:30 UTC by Dariusz Gadomski
Modified: 2015-07-21 11:51 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
log from mounting the share and trying to access the directories (58.44 KB, text/plain)
2015-07-14 07:49 UTC, Dariusz Gadomski
Details

Description Dariusz Gadomski 2015-07-07 12:30:39 UTC
Looks like the SMB backend does not support ACL rules while accessing remote shares.

The scenario looks like this:
1. LDAP authentication for client & server. 
2. SMB server with a share accessible to a certain ACL group or user.
3. A user (that should be allowed to access the share: is a member of the group or is an ACL user) accesses the share from a client using nautilus and smb:// URI.

Expected result:
Access is granted to the resource.

Actual result:
Permission denied for accessing the resource in question.
Comment 1 Ross Lagerwall 2015-07-13 22:49:28 UTC
Thanks for the report.

Can you clarify whether it is possible to access the share at all or whether it is only a particular resource within the share?

To get full debug output, please run the following in a terminal:
pkill gvfs; GVFS_DEBUG=all GVFS_SMB_DEBUG=10 `find /usr/lib* -name 'gvfsd'` &> ~/log.txt

Then attempt to mount the smb share, and upload log.txt in your home directory so we can see a log of what is happening. Thanks
Comment 2 Dariusz Gadomski 2015-07-14 07:49:15 UTC
Created attachment 307396 [details]
log from mounting the share and trying to access the directories

It is possible to access other resources in the share, except for those with ACL rules set.

Please find the log attached.

To give you some context: the user account I used in this case is user128. I have created 3 resources in the share:
dir1 - accessible to all
dir2 - with u:user128:rwx ACL rule set
dir3 - with g:miners:rwx ACL rule set (user128 is in the group 'miners')

Dir1 can be accessed without any issues, accessing dir2 or dir3 ends up with 'permission denied' message.
Comment 3 Ross Lagerwall 2015-07-18 19:06:04 UTC
As can be seen from the log, libsmbclient gives NT_STATUS_ACCESS_DENIED when trying to access dir2 and dir3. It looks like this bug lies within libsmbclient, which GVFS uses for accessing smb shares. Please raise a bug with the Samba project at https://bugzilla.samba.org/

Thanks
Comment 4 Ross Lagerwall 2015-07-18 19:06:40 UTC
It will probably be helpful to attach the above log onto the Samba bug.
Comment 5 Ondrej Holy 2015-07-21 09:18:16 UTC
(In reply to Ross Lagerwall from comment #3)
> As can be seen from the log, libsmbclient gives NT_STATUS_ACCESS_DENIED when
> trying to access dir2 and dir3. It looks like this bug lies within
> libsmbclient, which GVFS uses for accessing smb shares. Please raise a bug
> with the Samba project at https://bugzilla.samba.org/

It seems the log is from smb backend before commit a0aec32. I haven't investigated the code a lot, but I have just idea. Doesn't mean the following debug message that anonymous pass is used?
### SMB: auth_callback - anonymous pass

Consequently enumeration on the dir2 and dir3 fails from the obvious reason...
Comment 6 Dariusz Gadomski 2015-07-21 11:51:16 UTC
Thank you Ondrej. I have tried applying this patch, but despite the change in the log:
### SMB: auth_callback - kerberos pass
### SMB: auth_callback - out: last_user = 'user128', last_domain = 'WORKGROUP'

the outcome is still:
smbc errno NT_STATUS_ACCESS_DENIED -> 13

I will file a bug against samba.

Thank you.