Current approaches to ACL handling

Jeremy Allison jra at
Wed Oct 3 15:26:26 MDT 2012

On Wed, Oct 03, 2012 at 03:43:48PM -0500, Christopher R. Hertel wrote:
> I worked on ACL support back in '07, so I'm reviewing what's been
> done since then.  That's why I'm askin' questions.  :)
> If there is support for Posix ACLs in the underlying file-system,
> those can be used directly.  Also, there are some filesystems out
> there that support other ACL mechanisms.  Some of the proprietary
> file systems (OneFS, StorNext) have support for Windows ACLs.
> Jeremy's presentation from 2009 (mentioned earlier in this thread)
> covers different ways of leveraging that support.  It's best, of
> course, if the ACLs are stored in the file system and handled by the
> kernel.
> If, however, the underlying file system does *not* have support for
> any kind of ACL, then there's the EA method.  EAs can be used to
> store the ACLs, but this method clearly doesn't provide any kernel
> support for enforcing them.
> ...and this is all much better than the old method of encoding DOS
> FAT attribute bits into the file mode bits.
> I am still catching up on this topic.  I'm a bit out of the loop, so
> I'll encourage my colleagues to hit me with the clue bat.

+1 on this - completely accurate. The one thing we're really
missing is RichACLs on Linux, which are essentially the
local NFSv4 ACLs.

As they still differ from Windows ACLs I'd still recommend
the two-step mapping method (store the Windows ACLs into
an EA along with a hash of the underlying ACL) but it'll
get much closer to an accurate representation of the underlying
permissions (and no one would be happier than me than to one
day remove the POSIX ACL mapping code :-).


More information about the samba-technical mailing list