illumos gate

Of intrest, our behavior seems to match the samba bahavior.

If you are part of the 'admin users' property for a share (aka domain admin) you basically ignore all ACLs set when accessing the data via samba.

So that seems to match what is happening here.

Does this behavior match Windows' behavior? It just doesn't jive with how ACLs usually operate. At the very least, it's inconsistent with NFS4 ACLs, which as you'd imagine, have no notion of a super admin. Does samba do this when joined to a domain rather than explicitly setting an "admin users" list in their local user database?

I believe, if you use the 'net' to add a user or group to the Adminisators or... I forgot the name of the another group, yes... it will have the same behavior.

On the point of ACLs... NFS4 ACLs != Windows ACLs though, they do not map a 100%

Just tried sharing a file on Windows 10 to another windows host with permission share permissions but an ACL on a file was restricted in such a way that only the owner could do anything with it. I received access denied from the domain admin's access (the file is owned by an otherwise ordinary user).

This is definitely a bug in that it doesn't match Windows' behavior.

We have a fix for this. It's even in the "upstream" queue already.
Just takes time...

Gordon, can you point me to where these fixes are, or are they in a closed repo? I just want to make sure we're referring to the same bug behavior.

The fix for this issue modifies handling of "take ownership" privilege in the illumos SMB server to make it more consistent with behavior of Windows servers. The "take ownership" privilege is normally granted to members of the local Administrators group (i.e. local Administrator or "Domain Administratror").

Both illumos and Windows allow an SMB user with "take ownership” privilege (i.e. Administrator) to access any file or directory in an SMB share. However earlier versions of the server allow that access directly where Windows allows that access only via a two-step process where one first must “take ownership” of the objects, and then may access them. It's important to note that in the end the access is the same; only the number of steps it takes to get that access differs. With the fix for this issue in place, the illumos SMB server behaves the same as Windows; requiring an administrator to use the “two step" process of taking ownership of the objects, then accessing the objects.

System administrators who prefer the previous behavior of the SMB Administrator account having direct access to objects (without first taking ownership), may add either or both of two new privileges: "bypass ACL read", and "bypass ACL write" to the local Administrators group. Adding both of those privileges lets members of the group directly access all files and directories in an SMB share. Adding just "bypass ACL read" can be useful in deployments where an SMB account is being used to replicate data from a share and the system administrator would prefer to avoid the risk of that account accidentally modifying data.

Instructions for modifying SMB group privileges are found in https://illumos.org/man/smbadm.1m

Fix is out for review as part of this PR:
https://github.com/illumos/illumos-gate/pull/68