Current approaches to ACL handling

Christopher R. Hertel crh at
Mon Oct 8 10:05:08 MDT 2012

On 10/08/2012 06:23 AM, Alexander Werth wrote:
> On Wed, 2012-10-03 at 13:36 -0700, Jeremy Allison wrote:
>> On Wed, Oct 03, 2012 at 04:29:02PM -0400, J. Bruce Fields wrote:
>>> On Wed, Oct 03, 2012 at 02:48:00PM -0500, Christopher R. Hertel wrote:
>>>> On 10/03/2012 08:48 AM, J. Bruce Fields wrote:
>>>>> On Mon, Oct 01, 2012 at 02:36:20PM -0500, Christopher R. Hertel wrote:
>>>>>> On 10/01/2012 02:27 PM, Scott Lovenberg wrote:
>>>>>> :
>>>>>>> While we're all playing this game, I'll chime in with performance of a
>>>>>>> userland database versus in kernel structures and extra context
>>>>>>> switching. :)
>>>>>> Hey, you get RichACLs into the kernel and we'll be happy to use 'em.  :)
>>>>>> Even if EA's in are in the file system, we still need to read them
>>>>>> out and process them in userland.  I think there are a few small
>>>>>> dragons to be dealt with there, particularly across a cluster.
>>>>> As there are for the actual file data and normal attributes.  Yes, there
>>>>> may well be bugs, but they're filesystem bugs....
>>>> I meant that enforcing ACLs that are stored in EAs requires reading
>>>> them into userspace and enforcing them there.  It's not a filesystem
>>>> issue, it's a problem of synchronizing the interpretation of the
>>>> meta-data between multiple processes (possibly across multiple
>>>> machines) and the kernel(s).
>>> I thought Samba depended on the posix acl for enforcement?  Or does it
>>> do both?
>> It can deny based on the Windows ACL entry, but currently
>> then relies on the POSIX ACL underneath. We don't (yet)
>> allow a Windows ACL allow to override POSIX. We might
>> do that at some point.
>> Jeremy.
> In think an override of the kernel checks is necessary to get better ACL
> compatibility. That's because the some of the posix operations samba
> uses to execute a specific cifs call require more permissions by the
> kernel than the cifs call they implement.
> And the situation will get worse with the fine grained Rich ACL support
> in the kernel.
> For example the permission to read the permissions might not be granted
> on a file but Samba will expect to be able to read and evaluate the
> permissions for an open call nevertheless.
> Alexander Werth

There is an inherent mismatch between the semantics of Windows ACLs and the 
models available in Linux/Unix, including the RichACL model.  There will 
never be a pure 1:1 mapping.

Getting RichACLs into the kernel has been a point of discussion for years. 
While I agree that RichACL support in the kernel will introduce its own set 
of fine-grained problems for Samba, I would also say that the result will be 
closer to Windows behavior than what we have now.

Samba's leading role is, and always has been, to present Windows 
semantics--as closely as we can--while running on top of non-Windows 
platforms.  It's a difficult dance.

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.

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