[Samba] Warning messages when provisioning an ADDC

[Thomas]

Am 2/9/21 um 9:58 AM schrieb Ralph Boehme:
> hm, hm, with the acl_xattr VFS module with "acl_xattr:ignore system acls" set to yes we're already relying on userspace 
> for security bypassing the kernel, so I wonder whether the namespace issue is really the one I would worry about. 
> As long as users don't have direct access to the server storing the xattr in the user namespace might be an option.

Running the Samba ADDC in an unprivileged container is one aspect and more of a short term goal of enabling NFSv41 ACLs for provisioning.

As Andrew wrote the other aspect would be to enable the use of filesystems that natively support NFSv41 ACLs.
As far as I know GPFS already does this. Unfortunately the port of ZFS to Linux, now OpenZFS on Linux, did not implement the existing NFSv41 ACL support from Solaris ZFS.
However, there is some work under progress to implement ZFS native NFSv41 ACL support in OpenZFS although I'm not sure how that is currently progressing.
See OpenZFS issue https://github.com/openzfs/zfs/issues/4966 and pull request https://github.com/openzfs/zfs/pull/9709
So this would  more a long term goal.

In the meantime I was successful to remove the requirement of including the posixacl vfs module in the vfs objects option by boldly commenting out this check for the support of POSIX ACLs in the provisioning script:

        """
        file = tempfile.NamedTemporaryFile(dir=os.path.abspath(sysvol))
        try:
            try:
                smbd.set_simple_acl(file.name, 0o755, system_session_unix(), gid)
            except OSError:
                if not smbd.have_posix_acls():
                    # This clue is only strictly correct for RPM and
                    # Debian-like Linux systems, but hopefully other users
                    # will get enough clue from it.
                    raise ProvisioningError("Samba was compiled without the posix ACL support that s3fs requires.  "
                                            "Try installing libacl1-dev or libacl-devel, then re-run configure and make.")

                raise ProvisioningError("Your filesystem or build does not support posix ACLs, which s3fs requires.  "
                                        "Try the mounting the filesystem with the 'acl' option.")
            try:
                smbd.chown(file.name, uid, gid, system_session_unix())
            except OSError:
                raise ProvisioningError("Unable to chown a file on your filesystem.  "
                                        "You may not be running provision as root.")
        finally:
            file.close()
        """

The proper way to fix this would of course be to first check if POSIX ACLs are required, i.e. a check could be made if the "acl_xattr:ignore system acls" option is set.

The next problem I'm facing is that "samba-tool ntacl sysvolcheck" is for some reason doing a check to read ntacls via the vfs layer and also directly.
From the code in "checksysvolacl":

# Ensure we can read this directly, and via the smbd VFS
    session_info = system_session_unix()
    for direct_db_access in [True, False]:

Unfortunately Rowlands comment:
> This is probably because not only are GPO's stored in Sysvol, they are 
> in AD as well and the AD access ACL's are based on the Sysvol Acl's.
didn't really help me to understand the reason. Obviously my understanding of the Samba ADDC is too limited. Does it mean that the AD part is reading the sysvol ACLs directly and not via the VFS layer ?

However, boldly removing the "True" from the list over which the loop runs I can now run the sysvolcheck but it reveals that the ACLs are not properly set.
It throws an exception right at the sysvol/${REALM} directory.
Running "samba-tool ntacl sysvolreset" does complete without any error messages but only fixes the ACL for the afore mentioned sysvol/${REALM} directory.
Running sysvolcheck afterwards throws an exception for the ACL of sysvol/${REALM}/Policies/{6AC1786C-016F-11D2-945F-00C04FB984F9}
So for some reason sysvolreset did not fix this although it completed without reporting any issues.

So it looks like I'm already in the middle of the wackamole that Rowland suspected. :-)