Bug 6154 - zfs does not honor admin users
Summary: zfs does not honor admin users
Alias: None
Product: Samba 3.3
Classification: Unclassified
Component: VFS Modules (show other bugs)
Version: 3.3.0
Hardware: x86 Solaris
: P3 normal
Target Milestone: ---
Assignee: Jeremy Allison
QA Contact: Samba QA Contact
Depends on:
Reported: 2009-03-03 11:33 UTC by mchugh19@yahoo.com
Modified: 2009-03-05 17:19 UTC (History)
0 users

See Also:

smb.conf (1.14 KB, application/octet-stream)
2009-03-03 11:35 UTC, mchugh19@yahoo.com
no flags Details
samba logs (11.90 KB, application/x-gzip)
2009-03-03 11:42 UTC, mchugh19@yahoo.com
no flags Details
debug 10 logs (547.84 KB, application/x-gzip)
2009-03-04 09:09 UTC, mchugh19@yahoo.com
no flags Details
Patch for 3.3.1. (572 bytes, patch)
2009-03-04 18:47 UTC, Jeremy Allison
no flags Details
Second part of patch. (1.64 KB, patch)
2009-03-04 19:01 UTC, Jeremy Allison
no flags Details
Second part of patch (631 bytes, patch)
2009-03-04 19:17 UTC, Jeremy Allison
no flags Details
debug 10 logs (342.75 KB, application/gzip)
2009-03-05 12:05 UTC, mchugh19@yahoo.com
no flags Details
Third part of patch. (3.56 KB, patch)
2009-03-05 13:10 UTC, Jeremy Allison
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description mchugh19@yahoo.com 2009-03-03 11:33:06 UTC
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.
Comment 1 mchugh19@yahoo.com 2009-03-03 11:35:22 UTC
Created attachment 3966 [details]

aclinherit and aclmode in zfs are set to passthrough
Comment 2 mchugh19@yahoo.com 2009-03-03 11:40:11 UTC
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/

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/

But I'm connecting to samba with a username in the admin users group: ( 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.
Comment 3 mchugh19@yahoo.com 2009-03-03 11:42:09 UTC
Created attachment 3967 [details]
samba logs
Comment 4 Jeremy Allison 2009-03-03 12:09:00 UTC
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....
Comment 5 Jeremy Allison 2009-03-03 12:15:57 UTC
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).
Comment 6 mchugh19@yahoo.com 2009-03-03 14:30:47 UTC
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.
Comment 7 Jeremy Allison 2009-03-03 19:18:45 UTC
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.
Comment 8 mchugh19@yahoo.com 2009-03-04 09:09:05 UTC
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.
Comment 9 Jeremy Allison 2009-03-04 12:51:07 UTC
Ah, ok - thanks. Now I see the codepath that needs fixing. Stand by for a patch (will be in 3.3.2).
Comment 10 Jeremy Allison 2009-03-04 18:47:10 UTC
Created attachment 3971 [details]
Patch for 3.3.1.

Can you try this patch out. It should fix the issue you reported.
Comment 11 Jeremy Allison 2009-03-04 19:01:27 UTC
Created attachment 3972 [details]
Second part of patch.

Ah, sorry - you need this part as well.
Comment 12 Jeremy Allison 2009-03-04 19:17:37 UTC
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).
Comment 13 mchugh19@yahoo.com 2009-03-05 10:34:13 UTC
That does seem to fix it. Thanks much!
Comment 14 Jeremy Allison 2009-03-05 10:58:39 UTC
Fixed with applied patches. Will be in 3.3.2.
Comment 15 mchugh19@yahoo.com 2009-03-05 12:05:19 UTC
I think I managed to find a case where it is still not working. I will attached debug 10 logs in a bit.
Comment 16 mchugh19@yahoo.com 2009-03-05 12:05:49 UTC
Created attachment 3975 [details]
debug 10 logs
Comment 17 mchugh19@yahoo.com 2009-03-05 12:08:10 UTC
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 .
root@rieekan:/raid/dropbox$ ls -ldV New\ Folder/
drwxr-xr-x   2 root     10000          3 Mar  5 10:55 New Folder/
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

However, I'm able to rm -r New\ Folder from a terminal as root.
Comment 18 mchugh19@yahoo.com 2009-03-05 12:13:44 UTC
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)
Comment 19 Jeremy Allison 2009-03-05 12:37:10 UTC
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.


Comment 20 mchugh19@yahoo.com 2009-03-05 12:56:03 UTC
(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.
Comment 21 Jeremy Allison 2009-03-05 13:10:16 UTC
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 !
Comment 22 Jeremy Allison 2009-03-05 13:52:16 UTC
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 !
Comment 23 mchugh19@yahoo.com 2009-03-05 14:19:12 UTC
(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!
Comment 24 Jeremy Allison 2009-03-05 17:19:34 UTC
Ok, confirmed fixed. Pushed.