The samba zfs module allows for using the nfsv4 acls of Solaris' zfs. However, even though I can connect to samba as a user defined in admin users, and the samba logs show my attempts connecting as uid=0, I'm not able to set permissions for files/directories that I do not already have an ace for.
Created attachment 3966 [details] smb.conf aclinherit and aclmode in zfs are set to passthrough
I am able to connect from a windows client and browse to the /raid/ directory. root@rieekan:/raid$ ls -lVd /raid/ drwxrwxrwx+ 7 root root 7 Mar 3 10:22 /raid/ everyone@:rwxpdDaARWcCos:fd----:allow However, I'm not able to access the /raid/clinttest/ directory from windows because of permission denied root@rieekan:/raid$ ls -lVd /raid/clinttest/ d---------+ 2 root 10000 2 Mar 3 10:22 /raid/clinttest/ user:NAU-STUDENTS\cwb32:rwxpdDaARWcCos:fd----:allow But I'm connecting to samba with a username in the admin users group: 134.114.144.151 (134.114.144.151) connect to service testing initially as user NAU-STUDENTS\mmchugh (uid=0, gid=10000) (pid 26359) With this being the case, how am I supposed to administer a samba share on zfs with acls? In windows you can specify the list of admins that are able to take ownership in group policy. It appears that with zfs only the acls matter and thus I would have to explicitly allow the admin group to take ownership and allow permissions setting for every file and folder.
Created attachment 3967 [details] samba logs
So you're telling me that ZFS is refusing access to a process with uid = 0 ? That breaks POSIX semantics. Samba requires a POSIX system.... Jeremy.
Can you try 3.3.1, there are some fixes w.r.t. ZFS ACLs in this version (although there may still be one more patch needed to cope with directory renames on ZFS). Thanks, Jeremy.
I'm not exactly sure how the zfs vfs module deals with samba. To the best of my knowledge zfs natively deals with nfsv4 acls, and uses the posix stuff on top. So I believe that the vfs module works with the native nfsv4 acls. As root ssh'ed into the machine I am able to change acls with no problems. But if I connect as a user in the admin users list, I'm not able to mess with permissions, unless granted by the acl. So I don't know if I'd say "ZFS is refusing access to a process with uid = 0" so much as the zfs module is not mapping with admin users properly.
Get me a debug level 10 log, and please try with 3.3.1, I'll take a look. I don't have a Solaris box with ZFS on it to test with. Jeremy.
Created attachment 3969 [details] debug 10 logs Here of the logs from samba 3.3.1 of mmchugh connecting (a user in the admin users list) and then trying to access the security tab of the clinttest directory. The clinttest directory only allows access for a single ace that is not mmchugh. In the windows security tab I only see a message "You do not have permission to view or edit this object's permission settings" so I'm not even able to attempt to set permissions to get the standard permission denied error.
Ah, ok - thanks. Now I see the codepath that needs fixing. Stand by for a patch (will be in 3.3.2). Jeremy.
Created attachment 3971 [details] Patch for 3.3.1. Can you try this patch out. It should fix the issue you reported. Thanks, Jeremy.
Created attachment 3972 [details] Second part of patch. Ah, sorry - you need this part as well. Jeremy.
Created attachment 3973 [details] Second part of patch Oops. Sorry, here is the real second part of the patch (included too much in the previous version). Jeremy.
That does seem to fix it. Thanks much!
Fixed with applied patches. Will be in 3.3.2. Jeremy.
I think I managed to find a case where it is still not working. I will attached debug 10 logs in a bit.
Created attachment 3975 [details] debug 10 logs
The following hierarchy seems to not allow deletes of either "New Folder" or the .lnk inside root@rieekan:/raid/dropbox$ ls -ldV . drwxrwxrwx+ 3 root 10000 3 Mar 5 10:55 . everyone@:rwx---a---c--s:------:allow root@rieekan:/raid/dropbox$ ls -ldV New\ Folder/ drwxr-xr-x 2 root 10000 3 Mar 5 10:55 New Folder/ owner@:--------------:------:deny owner@:rwxp---A-W-Co-:------:allow group@:-w-p----------:------:deny group@:r-x-----------:------:allow everyone@:-w-p---A-W-Co-:------:deny root@rieekan:/raid/dropbox$ ls -ldV New\ Folder/Control\ Panel\ -\ Shortcut.lnk -rw-r--r-- 1 root 10000 104 Mar 5 10:55 New Folder/Control Panel - Shortcut.lnk owner@:--x-----------:------:deny owner@:rw-p---A-W-Co-:------:allow group@:-wxp----------:------:deny group@:r-------------:------:allow everyone@:-wxp---A-W-Co-:------:deny However, I'm able to rm -r New\ Folder from a terminal as root.
As a little bit more clarification, as mmchugh on a windows machine attempting to delete the file, I am able to tell it to delete and it goes away. However, if I hit refresh on the folder it immediately shows up again. The delete appears to succeed but does not actually remove the file. If I attempt to delete "New Folder" with the .lnk still inside it never appears to go away (I suspect do to the lack of actually removing the .lnk inside)
Ok, your log shows the problem. Inside log.smbd we have : 46991 close_remove_share_mode: file dropbox/New Folder/Control Panel - Shortcut.lnk. Change user to uid 62107 So the delete was done as uid 62107, who I'm assuming was NAU-STUDENTS\mmchugh. Is this user listed in the admin users list ? What happens is we store off the uid of the user requesting the delete (when they set the delete on close bit), and become that user in the close() call (to make sure we're doing it as the correct user. The critical call is : set_delete_on_close(fsp, True, &conn->server_info->utok) within smbd/trans2.c:smb_set_file_disposition_info(5141) where conn->server_info->utok is the UNIX token representing the user on this particular connection struct (uid, gid and supplementary group list). For some reason this isn't correctly storing the unix user token as uid zero (root). Still investigating. Jeremy.
(In reply to comment #19) > So the delete was done as uid 62107, who I'm assuming was NAU-STUDENTS\mmchugh. > Is this user listed in the admin users list ? Yes. Thanks Jeremy.
Created attachment 3976 [details] Third part of patch. Ok - try this (additional) patch. Should fix it by ensuring that admin users get a stored uid of zero in their delete on close stored UNIX token. Thanks a *lot* for helping me track this down ! Jeremy.
If you can confirm the patch for me today (or at least by Friday), I can get it into the code for 3.3.2 which we're planning to ship pretty soon. Thanks ! Jeremy.
(In reply to comment #21) > Ok - try this (additional) patch. Should fix it by ensuring that admin users > get a stored uid of zero in their delete on close stored UNIX token. Seems to be fixed again. Thanks!
Ok, confirmed fixed. Pushed. Jeremy.