Are there any simple and integrated (i.e. embedded into filesystem) ACL patches for Linux kernel exist at all?

The problem is simple: I need something more flexible and advanced beyond classic 'rwx' chmod on Linux.

My requirements are:

  • Having more fragmented restrictions:
    • At least permit user to delete, but not to create
    • Reverse: permit create and append, but not delete
    • Hide files from anyone except superuser and owner/group
    • It is better to fragment those into separate permission flags
  • Separated permissions for files and directories
  • More advanced control over appending to files/directories
  • Large number of permission entries going beyond standard user:group model (like POSIX ACL does)
  • Being integrated into filesystem (perhaps via xattrs)
  • Not requiring sophisticated and bloated programs and security frameworks (I already walked through grsecurity and I dislike it)
  • Unified tools to manage them from userspace

The reason for that is a number of advanced file servers I usually build become very limited or insecure because there is only so limited POSIX ACL exist which only extends a number of 'rwx' entries on inode.

Things that are not apply here:

  • Any Linux kernel LSM (SELinux etc.)
  • chattr/lsattr
  • grsecurity

And as last resort, if there are no any packages/kernel patches providing such functionality, then I will be forced to start hacking my own.

  • 1
    On most filesystems, the number of POSIX ACL permission entries is limited. Dec 1, 2015 at 14:00
  • OK will take into account!
    – user140866
    Dec 1, 2015 at 14:22

1 Answer 1


There is nothing that is called POSIX ACLs. What some people call POSIX ACLs is a draft proposal from 1993 that was withdrawn in 1997.

There is however a ACL standard: NFSv4 ACLs also known as NTFS ACLs.

NFSv4 ACLs are now supported by Solaris, Mac OS X, FreeBSD and AIX and even Linux started to implement them recently. On Linux they are called "richacls".

NFSv4 ACLs are supported natively on ZFS and on the filesystems from OS X and AIX.

See http://schillix.sourceforge.net/man/man1/chmod.1.html for a desription.

The new ACL standard is not really simple, but it implements what you like to see.

The NFSv4 ACL implementation on Linux was done by the same person who did the implementation for the withdrawn draft. Unfortunately on Linux, there is usually no ACL code installed by default. Also note that while Solaris supports up to 1024 ACL entries, the limit for Linux is much smaller. NTFS ACLs on Win-DOS support a maximum of 1820 entries.

You might be interested that last year, there was no working library support for SuSE Linux and as a result, I could not yet add Linux NFSv4 ACL support to star while this exists for Solaris, OS X and FreeBSD.

Note that there is only broken ACL support in gtar, so if you like to play with ACLs, you would need to use staranyway.

P.S. If someone finds a Linux system with working NFSv4 acls, send me a note. I am interested to add Linux NFSv4 support to star even though they seem to use an incompatible library interface.

  • The thing exists but without name :-) OK, I am aware of NFSv4 ACLs (last time I checked them at beginning 2012), and indeed I need sort of NTFS ACL, but the thing that scared me is NFS. Do Linux version (if any) require NFS code linked in? And do you know what is status of those "richacls"?
    – user140866
    Dec 1, 2015 at 14:22
  • @siblynx, they're called NFSv4 ACLs, because that's the ACLs specified in the NFSv4 specification. Like schily says, there's a richacls patch for Linux as a superset of that. Some versions of opensuse have had the patch applied. The patch might end up being merged upstreams in linux-4.4 Dec 1, 2015 at 14:31
  • @Stéphane Chazelas That's nice news, I hope it will go mainstream! So I got that right - richacls do not depend on nfs at all and just work with any reasonable filesystem? That's a reason to upgrade the kernel. I will look into this tomorrow. I hope at least kernel part will be reasonable, and userspace tools (if any) will be able to be built with libc other than glibc.
    – user140866
    Dec 1, 2015 at 14:46
  • 1
    I mark this question solved because the description of richacls from Wikipedia satisfies my requirements well. I need kernel upgrade though, it may not be as easy as because I have some custom patches, but I hope it will not break. It also provides userspace program. If I will dislike it for some reason, I am free to start hacking my own implementation. I also did not know about richacls patch, thanks for the info @schily!
    – user140866
    Dec 1, 2015 at 15:26
  • 1
    Long time passed, I returned to issue. Quickly analyzed richacls and disliked it. Since I am going to fork off Linux kernel and make a local version to use which also will be published, I decided to extend it with my own extacl ascii acls set. The code is already working, although is still WIP.
    – user140866
    May 2, 2016 at 17:14

You must log in to answer this question.