Why we aren't tempted to use ACLs on our Unix machines

September 5, 2015

One of the things our users would really like to have is some easy way to do ad-hoc sharing of files with random collections of people. In theory this is a great fit for ACLs, since ACLs allow users themselves to extend various sorts of permissions to random people. Despite this appeal of ACLs, we have no interest in supporting them on our machines; in fact, we go somewhat out of our way to specifically block any chance that they might be available.

The core problem is that in practice today, ACL support is far from universal and not all versions of it behave the same way and are equally capable. What support you get (if any) depends on the OS, the filesystem, and if you're using NFS (as we are), what the NFS fileserver and its filesystem(s) support. As a practical matter, if we start offering ACLs we're pretty much committed to supporting them going forward, and to supporting a version of them that's fully backwards compatible with our initial version; otherwise users will likely get very angry with us for taking away or changing what will have become an important part of how they work.

(The best case on an ACL system change is that people would lose access to things that they should have access to, partly because people notice that right away. The worst case is that some additional people get access to things that they should not.)

Given that neither ACL support nor ACL behavior is anywhere near universal, a need for backwards compatibility is almost certain to limit our choice of future OSes, filesystems, and so on. Do we want to switch the fileservers to FreeBSD, for example, but NFS to ZFS on FreeBSD doesn't support the ACL semantics we need? We'd be out of luck and stuck. If we want the most future freedom we have to stick to the lowest common denominator, and today that is Unix UIDs, GIDs, and basic file permissions.

(This sort of future compatibility is not a universal need, of course. There are any number of environments out there where you build systems for specific needs and when those needs go away you're going to toss the systems. In that setup, ACLs today for one system don't necessarily imply ACLs tomorrow (or the same ACLs tomorrow) for another one.)

Comments on this page:

By Lev at 2015-09-06 23:09:28:

What we do for our shared storage is a solution with 95% POSIX ugo/rwx and 5% ACL. Sharing controlled by regular permission bits and membership in regular Unix groups. The only ACL piece used is to force proper inheritance of parent dirs rights and memberships for newly-created files (i.e. for overriding user's umask, not for enabling/disabling access by any other users). Seems like a reasonable compromise and so far works pretty well (users are happy).

Written on 05 September 2015.
« Consistency and durability in the context of filesystems
Optimizing finding unowned files on our ZFS fileservers »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sat Sep 5 01:08:36 2015
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.