You may find your respondent (the coauthor of Samba), as well as a lot of Samba users, disagree with your somewhat contentious comment that ACLs in Samba 'do[] not work at all'!
Posted Dec 2, 2011 7:54 UTC (Fri) by trasz (guest, #45786)
[Link]
Let me rephrase: while ACLs in Samba work in some specific, even if common, cases, they don't work in the general case. That's because it's impossible to "emulate" NTFS/NFSv4 ACLs on top of POSIX.1e ACLs, which is what Samba is trying to do - these two differ even in fundamental ways, e.g.in the way ACL entries are evaluated. In order to support ACLs properly Samba would have to either ditch support for systems that don't support NFSv4 ACLs natively (i.e. Linux), or just store the ACLs independently from the filesystem.
Releasing Samba 4
Posted Dec 2, 2011 18:51 UTC (Fri) by jra (subscriber, #55261)
[Link]
You're obviosly unaware of the acl_xattr module shipped in modern Samba, and used by most OEMs.
This stores "pristine" Windows ACLs in an EA on the filesystem, and consults them before allowing access to the underlying file/directory. The mapping to underlying POSIX ACLs (for systems that don't support them) is done underneath this layer for compatibility with NFSv3 and system process accessing the same files.
Samba of course has a full mapping into NFSv4 (ZFS, or GPFS) ACLs, which will be supported on Linux once the "RichACLs" patch is accepted into the kernel.
So yes, ACLs *do* work in the general case in Samba, and many successful OEMs ship with them turned on.
Jeremy.
Releasing Samba 4
Posted Dec 5, 2011 9:40 UTC (Mon) by trasz (guest, #45786)
[Link]
Yup, my bad. I didn't know about this module.
Releasing Samba 4
Posted Feb 8, 2012 7:19 UTC (Wed) by kaiser (guest, #82799)
[Link]
It's my experience that most users want ACLs which interoperate with the native filesystem as well as NFSv3/v4--in other words, they want their permissions to be the same regardless of access protocol. In this respect I think Sun and Isilon did it right by integrating ACL/SID support directly into the kernel.
This fixes some minor interop. nits (group owners of files, for example) but also allows the Windows privilege model to be integrated as a first class citizen in the OS, and most importantly, allows for SIDs to be stored natively as the user's in-kernel credentials, which is a real boon for identity management/mapping across protocols, and for group policy (e.g. local groups). As a bonus, this allows any userspace CIFS processes to run without escalated privilege (e.g. switching to root for take ownership) which can be seen as a security risk.