Current approaches to ACL handling
Christopher R. Hertel
crh at ubiqx.mn.org
Mon Oct 8 13:53:36 MDT 2012
On 10/08/2012 01:31 PM, J. Bruce Fields wrote:
> On Mon, Oct 08, 2012 at 11:05:08AM -0500, Christopher R. Hertel wrote:
>> If we were to get Windows ACL support in the kernel, the next
>> problem would be mapping those ACLs to the behaviors that Linux
>> software expects. There's an inherent conflict that has to be
>> resolved, so the question is where and how to resolve it. There are
>> a lot of viable schemes out there, but as a general solution we've
>> always found that the most acceptable solution is to have Samba be
>> the adaptive piece, and not try to pass the semantic conflicts off
>> to the kernel or other applications.
> I don't understand your last sentence. (What is an "adaptive piece",
> and what would it mean for Samba to "pass the semantic conflicts off to
> the kernel or other applications"?)
Well... that sentence was intentionally vague because I didn't want to go
into the details of specific semantic behaviors. Alexander's earlier e'mail
also touched on, but did not specify, the handling of semantic differences.
So I am speaking in generalities here. Thus your question.
Okay, so, consider the current system of applying Windows Deny ACLs in
userspace and then using POSIX ACLs at the kernel level (as Jeremy
described). The "adaptive piece" is the Samba code that stores the Windows
ACLs in EAs and applies the Windows Deny ACLs in user space. That adapts
the Windows semantics to the underlying POSIX semantics, and gives us
something very close to what the end user expects.
...but it gets tricky. What if the underlying POSIX ACLs are changed by
some other process? What do we report back to the SMB client?
If I understood Alexander's suggestion, it was to implement Windows ACLs in
the filesystem/kernel. That would mean that Samba would no longer need to
adapt because the semantics would be what we'd expect.
On the other hand, how would the kernel go about enforcing some of the more
obscure permissions for non-Samba processes? How would NFS interpret the
ACLs? What about local processes? Which permissions would be exposed to
the local user and which would not? The adaptations would have to move,
probably into the kernel with the new ACL type.
A solution I have seen is to store multiple types of ACL in the file system.
In some cases, there is an effort to synchronize changes to one ACL type
by mapping the changes over to the other ACL type. Another approach is to
simply keep the two (or three) separate and have entirely different access
rules apply depending upon who's asking. No, really.
Does that help or have I just made things muddier? It's a complicated set
"Implementing CIFS - the Common Internet FileSystem" ISBN: 013047116X
Samba Team -- http://www.samba.org/ -)----- Christopher R. Hertel
jCIFS Team -- http://jcifs.samba.org/ -)----- ubiqx development, uninq.
ubiqx Team -- http://www.ubiqx.org/ -)----- crh at ubiqx.mn.org
OnLineBook -- http://ubiqx.org/cifs/ -)----- crh at ubiqx.org
More information about the samba-technical