ACL manager in 11.3 Beta 1

[anodos]

Above is a screenshot of the ACL manager in Beta 1. It's accessible by clicking on the three-dot menu next to the dataset entry under Storage in the new UI.
Path - indicates the path that's ACL is being displayed. The WebUI exposes this on a per-dataset level. The websocket API can take arbitrary paths that are located under /mnt/

User - the owner of the file in question
Group - the owner-group of the file in question
Default ACL Options - a few templates for the convenience of users (OPEN, RESTRICTED, HOME)

Each entry in the ACL has the following fields:
Who - [owner@, group@, everyone@, User, Group] The first three items are special entries. owner@ refers to the Owner, group@ refers to the Owner group, everyone@ refers to literally everyone. User and Group are used for explicit entries.

ACL Type - Allow or Deny

Permissions Type, Flag type - this allows you to select between advanced and simplified views of possible permissions and inheritance flag combinations.

There is also a "strip acl" checkbox, which can be used to remove extended ACLs from a path. Once you do this you can use the regular permissions editor to modify POSIX mode bits on the file.

If you check "recursive", then the specified ACL will be applied to recursively to the path in question, but not traverse to child datasets. If you check "traverse", then child datasets will be affected as well.

 

[MikeyG]

Thanks for this - it looks super promising.

Playing around with a simple test share, I have an AD group called "smb admins" which I've given full control of to share "test."

In windows, the top level share looks exactly as I'd expect:

However, when I go to create a file in the share, that file is getting additional groups applied to it:

I'm accessing the share and creating the file as AD\mike so that makes sense, although it's only setting my permissions like this:

On my production server running 11.2, this stuff all behaves much differently. Files I create get inherited permissions applied to them, with both my user "mike" and the group "smb admins" listed as having Full Control.

What am I doing wrong here?

 

[anodos]

Try adding the following auxiliary parameter to the smb share and see if it fixes the behavior:
ixnas:zfs_acl_chmod_enabled = false

I noticed recently that I was getting some unusual fchmod requests inside Samba's VFS that I haven't had time to track down yet. It might be caused by that. I'll do some testing with a windows VM in a second.

 

[anodos]

The extra entries for User, Group, Other can have three causes:
1) processing of chmod request from client
2) an internal samba operation being changed into a chmod
3) default ZFS acl inheritance operation.

(3) is possibly happening here as well. It appears that my workaround is still in place and functioning, but I'm going to test processing SMB2 setinfo requests from a windows client to see if I can break it.

 

[anodos]

Okay. I see what the problem is. I'll have a fix for Beta2.

 

[anodos]

Temporary workaround is to set the dataset aclmode to "restricted". Generally for best SMB behavior, you should select the SMB "share type" when creating the ZFS dataset. This applies create-time optimizations. It's fine to select "generic", but there will be minor behavior differences between the two.

 

[MikeyG]

ACL mode was set to restricted already, but that aux parameter seems to have fixed it.

Would be nice to know the impact of not setting share type to SMB at first and then converting later. If you do answer that, I mean the impact from an admin perspective, and not necessarily just the technical underpinnings of what's going on.

Curious to see how all this shakes out in the coming months. The ACL editor seems to be great, but the changes in how dataset permissions and smb ACls work and combine is (at least for me) a confusing change. I'm used to being able to set something as "Windows" and then just make all changes in Windows Explorer without worrying about it. I've also previous switched datasets from Unix permissions to Windows without any problems or odd behavior.

Anyway, thanks for the quick reply and temporary fix!

 

[anodos]

ACL mode was set to restricted already, but that aux parameter seems to have fixed it.

Would be nice to know the impact of not setting share type to SMB at first and then converting later. If you do answer that, I mean the impact from an admin perspective, and not necessarily just the technical underpinnings of what's going on.

In 11.3 the "share type" is a create-time option because one of the parameters that gets set is the dataset case sensitivity (which is immutable). From an admin perspective there should be almost zero difference. "Generic" share-type and an "SMB" share-type can both have ACLs set on them (or removed).

The ACL editor seems to be great, but the changes in how dataset permissions and smb ACls work and combine is (at least for me) a confusing change. I'm used to being able to set something as "Windows" and then just make all changes in Windows Explorer without worrying about it.

You may not have noticed, but the behavior you're concerned about seeing (with new owner, group, everyone entries appearing) is actually the default behavior in 11.2. It's a ZFS behavior that I'm subverting in samba to give a more windows-like experience with ACLs in vfs_ixnas.

I've also previous switched datasets from Unix permissions to Windows without any problems or odd behavior.
Anyway, thanks for the quick reply and temporary fix!

In 11.1 and 11.2 there was little difference between the different share types (all it did was change one ZFS property and set a default ACL). In 11.3, there are optimizations that users can decide whether they make sense for their specific application / usage (the UI form should automatically update to show the new dataset properties when you select "SMB" from the dropdown).

In 11.3 for SMB, you choose what dataset properties you want (use SMB template if your use case doesn't require a case-sensitive filesystem), and set an ACL. If you're unsure of what ACL to set, you can use one of the pre-defined template ACLs ("OPEN", "RESTRICTED", "HOME" currently). The 11.3 equivalent of switching from "Unix" to "Windows" is simply a matter of setting an ACL on the path (and maybe changing the ZFS aclmode from "passthrough" to "restricted" in the dataset properties). The reverse ("Windows" to "Unix") involves just checking the "strip acl" box in the webui (and the recursive box), hitting apply, and changing the aclmode dataset property to "passthrough".

Overall, the share types never really made much sense. We had "Mac, Windows, Unix", but there was no real difference between Mac and Unix, and Windows was a synonym for SMB. This meant that there was often confusion for new users about what to choose for the Share Type for an SMB share for Macs. The designation "share type" was maintained in 11.3. for legacy / compatibility reasons with the legacy REST API (v1).

 

[MikeyG]

Was the fix for this issue implemented in RC1? I just upgraded, re-created the share and still have the same issue.

 

[MikeyG]

Apologies - I just set the dataset to restricted and the permissions now work as expected when creating files. I had originally created it as generic instead of SMB which did not set this correctly.

Is there any way to switch this over automatically when a smb share is added to a generic dataset? Or add a prompt asking to do so? It might avoid some confusion.

 

[anodos]

Apologies - I just set the dataset to restricted and the permissions now work as expected when creating files. I had originally created it as generic instead of SMB which did not set this correctly.

Is there any way to switch this over automatically when a smb share is added to a generic dataset? Or add a prompt asking to do so? It might avoid some confusion.

I think the correct fix will be to make samba a little more aware of NFSv4 ACLs. This requires a change outside of the VFS so I have to approach it carefully.

 

[appliance]

i also swiftly installed RC, and it's the same or worse - the "ixnas:zfs_acl_chmod_enabled = False" hack doesn't have effect anymore, so i'm getting read permission for Everyone on a restricted dataset with the touch command.

 

[anodos]

i also swiftly installed RC, and it's the same or worse - the "ixnas:zfs_acl_chmod_enabled = False" hack doesn't have effect any more, so i'm getting read permission for Everyone on a restricted dataset with the touch command.

I believe this is happening because your application is sending an SMB2 setinfo request explicitly setting those permissions. You can perform a pcap of the traffic and verify for yourself, or you can send me a pcap of it.

Changing the default for the parameter ixnas:zfs_acl_chmod_enabled is not a hack. I wrote that portion of ixnas in 11.3 to manage an edge-case behavior in vfs_fruit where the POSIX mode is presented and managed through some special ACL entries.

 

[appliance]

I believe this is happening because your application is sending an SMB2 setinfo request explicitly setting those permissions. You can perform a pcap of the traffic and verify for yourself, or you can send me a pcap of it.

Changing the default for the parameter ixnas:zfs_acl_chmod_enabled is not a hack. I wrote that portion of ixnas in 11.3 to manage an edge-case behavior in vfs_fruit where the POSIX mode is presented and managed through some special ACL entries.

thanks. but why now it doesn't help in the same exact scenario? i reckon it's now standard parameter, i still use it or not, with the same result as above.

 

[anodos]

thanks. but why now it doesn't help in the same exact scenario? i reckon it's now standard parameter, i still use it or not, with the same result as above.

It matters because if your client requests to set certain permissions, we have no choice but to set them. This is how the SMB protocol works. Below is a portion of a pcap of cygwin "touch" a file.

As you can see, (apart from the garbage SID that cygwin sends over the wire) it explicitly sets the ACL you are seeing. I already gave you a workaround for locking down Cygwin's behavior (remove the ability to set ACLs from users). I'm not going to fix cygwin.