Current approaches to ACL handling

Christopher R. Hertel crh at
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 
of problems.

Chris -)-----

"Implementing CIFS - the Common Internet FileSystem" ISBN: 013047116X
Samba Team --     -)-----   Christopher R. Hertel
jCIFS Team --   -)-----   ubiqx development, uninq.
ubiqx Team --     -)-----   crh at
OnLineBook --    -)-----   crh at

More information about the samba-technical mailing list