[Samba] Recommended ACL-related settings (Samba/ZFS)?

[Andrew Walker]

Overview:
FreeBSD has native NFS41 ACLs with a few minor caveats regarding ACL
auto-inheritance bits. Tools to manage locally are "getfacl" and "setfacl".
The FreeBSD getfacl and setfacl commands support both POSIX1E and NFSv4
ACLs. It's important to format ACL entry strings correctly when setting so
that you're using the correct ACL branding for the filesystem in question.
POSIX1E ACLs are not supported on ZFS on FreeBSD. Operations that attempt
to set a POSIX1E ACL explicitly will fail (whether writing the xattr
directly or using acl_set_file() / acl_set_fd() with incorrect branding).
This is sometimes observed when using rsync or other tools that were not
designed with NFSv4 ACLs in mind.

Interplay between tools / syscalls that get and set conventional Unix
permissions and an NFSv4 ACL are configurable on ZFS through the zfs
dataset "aclmode" property. "aclinherit" property should be set to
"passthrough" because we want ACL inheritance.

--restricted--
this is my preferred default configuration for Samba shares. In this case,
if you have set a non-trivial ACL and a user / application decides to use a
non-acl-aware tool, then the operation fail with EPERM.
```
root at homenas[/mnt/dozer/ISO]# zfs get aclmode dozer/ISO
NAME       PROPERTY  VALUE        SOURCE
dozer/ISO  aclmode   restricted   local
root at homenas[/mnt/dozer/ISO]# chmod 777 ACLEXAMPLE
chmod: ACLEXAMPLE: Operation not permitted
```
The reason why this is the preferred choice is because when dealing with
users at scale (large environments), you do not want undefined / surprising
behavior with regard to permissions.

--passthrough--
This is a good choice for cases where you _don't_ want chmod() and friends
to fail with EPERM. chmod() succeeds and ACL entries for special ids (owner@,
group@, everyone@) on the file are adjusted to reflect the specified mode.*
However, in this case, it is often prudent to define your permissions in
named (non-special) entries so that chmod() will not result in relevant
permissions (like WRITE_ATTRIBUTES | WRITE_EXTENDED_ATTRIBUTES) being
stripped from your users. Example:
```
root at homenas[/mnt/dozer/ISO]# getfacl ACLEXAMPLE
# file: ACLEXAMPLE
# owner: isouser
# group: wheel
      user:smbuser:rwxpDdaARWcCos:fd-----:allow
            owner@:rwxp--aARWcCos:-------:allow
            group@:rwxp--a-R-c--s:-------:allow
         everyone@:rwxp--a-R-c--s:-------:allow
```

*if existing entries are inheritable and this is a directory, then
depending on ZFS version, they will receive an additional INHERIT_ONLY flag
so that original ACL is inherited on new file creation in the directory.

>2. Samba for SMB access serving Windows 10 and MacOS clients
Not much difference between clients in this regard. If you are using
vfs_fruit, it is generally probably a good idea to set `fruit:nfs_aces =
no`. It's better to not mix-and-match tools / syscalls that are ACL-aware
and are not ACL-aware.

>3. NFSv4 for NFS access serving Linux/Unix clients.
I would probably go with passthrough aclmode in this case

>4. HOME directories (with only the users full access)
owner@:full_set:fd:allow should be enough in most cases. Some NFS clients
get rather unhappy if the other special IDs are missing, so you can leave
them with `aRc`.

>(And some (Linux) users want the old mode bits and no ACLs at all… Sigh)
This is where you probably want passthrough with an ACE that still grants
access for an admin group. They get their playground to mess with things
however they want, but things are still somewhat manageable for a sysadmin.

>vfs objects = zfsacl
>nt acl support = yes
>store dos attributes = yes
>ea support = false
>nfs4:acedup = merge
^^^ these are fine

>zfsacl:denymissingspecial = yes
^^^ This will deny access if an admin / user removes CREATOR-OWNER /
CREATOR-GROUP aces. IMHO it's a POLA violation, but I understand why the
parameter exists. Unless you're sure you need it, remove.

>zfsacl:map_dacl_protected = yes
^^^ This allows you to disable auto inheritance from the Windows GUI. Good
idea to have generally.

I just realized there was a zfsacl bugfix for a certain edge case with
Linux client mounts with cifsacl option that I forgot to upstream. I'll put
it in with the other MR that I forgot about where we need to map WRITE_DATA
to WRITE_ATTRIBUTES | WRITE_EXTENDED_ATTRIBUTES.

Hope this clarifies things rather than muddies it up. If you have specific
questions, I'll answer as I have time.