The code in lib/replace/xattr.c used to work on FreeBSD as follows: 1. Attribute prefixed with "system." used to be mapped to EXTATTR_NAMESPACE_SYSTEM. 2. Any other attributes used to be mapped to EXTATTR_NAMESPACE_USER. 3. In any case the namespace name prefix used to be stripped. This was not ideal, but it worked. Now since #12490 has been "fixed" the code in lib/replace/xattr.c work as follows: 1. Attributes prefixed with "system." are mapped to EXTATTR_NAMESPACE_SYSTEM. 2. Attributes prefixed with "user." are mapped to EXTATTR_NAMESPACE_USER. 3. Any other attributes ARE REJECTED with ENOATTR. The problem is Samba uses "security.NTACL" to store NTACLs (in addition to mapping them to POSIX ACLs), and this behavior seems to be vital for Samba to work as AD DC. And now this attribute became invalid on FreeBSD. For instance, if you try to provision a new domain, samba-tool will fail with set_nt_acl_no_snum: fset_nt_acl returned NT_STATUS_INVALID_PARAMETER. ERROR(runtime): uncaught exception - (-1073741811, 'Unexpected information received') File "/usr/local/lib/python2.7/site-packages/samba/netcmd/__init__.py", line 176, in _run return self.run(*args, **kwargs) File "/usr/local/lib/python2.7/site-packages/samba/netcmd/domain.py", line 471, in run nosync=ldap_backend_nosync, ldap_dryrun_mode=ldap_dryrun_mode) File "/usr/local/lib/python2.7/site-packages/samba/provision/__init__.py", line 2175, in provision skip_sysvolacl=skip_sysvolacl) File "/usr/local/lib/python2.7/site-packages/samba/provision/__init__.py", line 1806, in provision_fill names.domaindn, lp, use_ntvfs) File "/usr/local/lib/python2.7/site-packages/samba/provision/__init__.py", line 1593, in setsysvolacl service=SYSVOL_SERVICE) File "/usr/local/lib/python2.7/site-packages/samba/ntacls.py", line 162, in setntacl smbd.set_nt_acl(file, security.SECINFO_OWNER | security.SECINFO_GROUP | security.SECINFO_DACL | security.SECINFO_SACL, sd, service=service)
Created attachment 13391 [details] Possible patch for master This should fix it. Can you test?
(In reply to Ralph Böhme from comment #1) The patch appears to solve the issue. Thanks.
Comment on attachment 13391 [details] Possible patch for master I don't think that is safe. I think it needs to be mapped to EXTATTR_NAMESPACE_SYSTEM. The issue is that the attributes are trusted (we can override permissions based on them), so need not to be modified except by root or perhaps the file owner - whatever the Linux semantics are.
On FreeBSD the EXTATTR_NAMESPACE_SYSTEM namespace has its own problem- this namespace is completely inaccessible from withing a jail. Unfortunately, this is a hardcoded behavior, not something that can be tuned. We have Samba AD DC running in a jail in production, moving NTACL to EXTATTR_NAMESPACE_SYSTEM will be a serious showstopper for us.
(In reply to Andrew Bartlett from comment #3) That would not be compatible with existing deployments (if there are any) where existing NTACL will be in the user namespace.
I'm not sure that use in a jail (just as use in a docker container) is compatible with the Samba security model.
(In reply to Andrew Bartlett from comment #6) What do you think is wrong with Samba in a jail (provided a man setting it up understands how stuff works)? You do not recommend (for a reason) using a single installation as a DC and as a file server at the same time, so running DC in one jail and file server in another on the same host sounds like a natural approach. Modern computers are too powerful to be only running Samba as DC for a small network of about 100 workstations. I don't run anything (except ntp and ssh daemons) in the host environment, and both jails are fully isolated one from another. Also I'm using VNET/VIMAGE, which means both jails have their own independent and fully functional network stack. So, can you please elaborate on what may be wrong with this setup?
(In reply to Andriy Syrovenko from comment #8) > What do you think is wrong with Samba in a jail The lack of access to the system. / EXTATTR_NAMESPACE_SYSTEM namespace is what concerns me.
(In reply to Andrew Bartlett from comment #9) OK, I think I now understand your concerns. User attribute data is protected according to the usual discretionary and mandatory protection rules, and that may or may not be a security problem, depending on how a particular system is setup. On the other hand FreeBSD guys have good reasons to keep system attributes inaccessible from jails. For what I've found, things like POSIX ACLs and MAC labels are stored as system extended attributes, and that is not something that should be accessible from the jail, indeed. I'd like to suggest a compromise. Can we restore the previous behavior (i.e. map "security." to EXTATTR_NAMESPACE_USER) at least in 4.6.x? For the future versions the ideal solution will be to map "security." to EXTATTR_NAMESPACE_SYSTEM by default, but at the same time make the ACL name (including the namespace part) that is used to store NTACLs configurable. Meanwhile, I'm going to check if I can use some kind of MAC policy to make NTACL attributes in user namespace be only accessible by root. Thanks.
*** Bug 12730 has been marked as a duplicate of this bug. ***
(In reply to Andriy Syrovenko from comment #10) It would be great if FreeBSD could introduce new namespaces. There is no real reason not to be able to, but, possibly, there are legacy concerns. The way it's implemented now allows to have dozens of new NSs, but seems, besides "system" and "user" NSes there are no conventions on them..
Ping.
My fix in bug #12490 broke this, the proposed patch in attachment #13391 [details] simply restores the previous behaviour. While I understand Andrews security concerns, I don't think that should be intertwined. Thoughts?
(In reply to Ralph Böhme from comment #14) Meanwhile I wrote a VFS module that takes care of this and introduces other variants of xattr handling. Let me clean it up a bit and send for the review. With introduction of the ZFS the security.NTACL issue became less important, as everything maps into NFSv4 ACLs.
(In reply to Timur Bakeyev from comment #15) Does AD DC embedded FS support NFSv4/ZFS ACLs (for sysvol share) already? It dodn't used to, and that's the main problem. Is your VFS plugin compatible with AD DC embedded FS?
(In reply to Andriy Syrovenko from comment #16) Well, FreeBSD port does support NFSv4 ACLs on ZFS. Not sure, what do you call 'embedded' FS, possibly - native FreeBSD ones? Well, Samba ports 4.7 and 4.8 work on ZFS OOTB with altered vfs objects line, on UFS - just as is, with the mapping of NTACL into user.NTACL xattr(which is not secure). My module supports this behavior, as legacy, for compatibility, also is able to map secure.* xattr into secure.* in the EXTATTR_SYSTEM_NAMESPACE(and can fall back to EXTATTR_USER_NAMESPACE in a jail). The question now is in transiting xattrs from one name space into another, as my module keeps original xattr prefixes for easier cooperation with Linux. I.e. it keeps prefixes, like user., system., secure., trusted. untouched.