aclmode=discard not supported?

[donalm]

I'm evaluating FreeNAS for a 99% Linux-client network. I'd prefer to set the aclmode to discard at the dataset level.

I can set this aclmode in the shell on FreeNAS, but it makes me nervous that it doesn't appear in the GUI. Is this configuration unsupported and/or is the product not intended for this use case?

When I later use the GUI to modify a dataset that I've switched to aclmode=discard, it throws an error:
[aclmode] Invalid choice: DISCARD
The error is raised here:
File "/usr/local/lib/python3.7/site-packages/middlewared/schema.py", line 53

So - I'm glad that the UI doesn't silently overwrite the value I've set manually.

Is there an alternative approach that is envisioned for Linux networks?

 

[Ericloewe]

aclmode=discard is what the GUI calls Unix permissions.

 

[anodos]

aclmode=discard is what the GUI calls Unix permissions.

Actually, 11.2 Unix permissions == passthrough. In 11.3 we removed the whole "Windows" and "Unix" think in favor of create-time presets. Currently they're just "SMB" and "Generic" for datasets. 11.3 changed so that it will directly expose the aclmode property (instead of secretly doing things behind the scenes.

I can set this aclmode in the shell on FreeNAS, but it makes me nervous that it doesn't appear in the GUI. Is this configuration unsupported and/or is the product not intended for this use case?

Regarding the other aclmodes, we only support passthrough and restricted, but it's not like your server will break if you change it from the CLI.

I can set this aclmode in the shell on FreeNAS, but it makes me nervous that it doesn't appear in the GUI. Is this configuration unsupported and/or is the product not intended for this use case?

Is there an alternative approach that is envisioned for Linux networks?

Client is mostly irrelevant in this case. For instance, you can set complex ACLs on a dataset being shared by NFSv3. The client will not be aware of the additional permissions, but the kernel will enforce them.

 

[donalm]

Thank you both very much for your replies -

I appreciate that NFSv3 clients will still be given access to files whose underlying permission mechanism is ACL, but this raises a concern I had with a competing product:

When the filesystem used ACLs as the underlying permission mechanism, the server would try to summarize those permissions into modebits (for NFS clients) that approximated the ACL permissions. Inevitably (because ACL is much more expressive) this has its limitations, so not all ACEs make it into that summary.

Specifically, it's trivial to add an ACE to a directory entry that grants a permission to some user(s), where that permission is hidden from any Linux user who inspects the file with ls or stat. So the 'badguys' group might have write access to a directory that looks to a Linux user as though it's 100% read-only.

(This was complicated by problems with nfs4_getfacl where it would sometimes return incorrect results, and sometimes return no result at all).

That's problematic for my domain. What I want is the reverse; the underlying filesystem permissions are modebits (or trivial ACLs, in FreeNAS terminology) and Windows clients get to see an ACL that reflects that. If the filesystem does something useful when a Windows client tries to modify permissions on a file, that's a bonus, but I'm fine with Windows clients being unable to set or modify permissions (beyond those required to create the file in the first place).

I appreciate that this may not be a very mainstream use case :)

As a side note - it's very welcome that the GUI doesn't silently overwrite the aclmode value I've set manually. Should I make a feature request, that the GUI displays and honors this rogue alcmode if it has already been set by some other mechanism? I'd worry that where the UI currently throws an error, this may be fixed in future in a way that 'corrects' the aclmode=discard.

Thanks again for your prompt help with this and congratulations on the 11.3 release. Notwithstanding this thread, it looks like a great product.

 

[anodos]

Okay. If we're talking SMB, you can create a dataset without ACL set and aclmode set to passthrough. Create an SMB share, remove the "ixnas" module and replace with "noacl", and restart samba. This module prevents windows clients from setting ACLs, and generates a windows SD exclusively from the POSIX mode bits. It also maps the write bits to the DOS "readonly" flag. So if the NFS client does chmod -w on a file, the windows client will see it as "readonly".

Changing to noacl may necessitate a client reboot before WIndows will remove the "Security" tab for files / directories in the share.

The ACL code in noacl is extremely simple:

Code:

static NTSTATUS noacl_fset_nt_acl(vfs_handle_struct *handle,
             files_struct *fsp,
             uint32_t security_info_sent,
             const struct security_descriptor *psd)
{
    return NT_STATUS_ACCESS_DENIED;
}

 

[donalm]

Ok excellent - I've enabled these modules and I'll run some tests:
noacl, offline, preopen, zfs_space, zfsacl

Thanks @anodos

 

[anodos]

Ok excellent - I've enabled these modules and I'll run some tests:
noacl, offline, preopen, zfs_space, zfsacl

Thanks @anodos

No. Those are incorrect. Remove zfsacl, offline, and preopen. zfs_space is fine.

 

[donalm]

Thanks @anodos - from the documentation:
Adding noacl requires adding the zfsacl object.

Is that incorrect?

I'll remove the preopen and offline modules.

 

[anodos]

Thanks @anodos - from the documentation:
Adding noacl requires adding the zfsacl object.

Is that incorrect?

I'll remove the preopen and offline modules.

That's old information. Is the UI prompting for that? :(

 

[donalm]

No the UI doesn't prompt for that. I just created a SMB share with those modules and it did not complain.

On clicking the "Save" button (with the noacl module enabled) it does immediately present the user with this dialog:
Configure ACL
Configure permissions for this share's dataset now?

But nothing worse than that.

 

[anodos]

No the UI doesn't prompt for that. I just created a SMB share with those modules and it did not complain.

On clicking the "Save" button (with the noacl module enabled) it does immediately present the user with this dialog:
Configure ACL
Configure permissions for this share's dataset now?

But nothing worse than that.

No ACLs are permitted on that dataset. Use the "permissions" editor to set mode bits.