That said, I agree that it would be most welcome if there were fewer niches where ACLs are still wholly unavailable: OpenBSD, tmpfs filesystems on FreeBSD, and so forth.
Both are good on their own. The hybrid model is complex and hard to manage, even though it can technically fulfill most requirements you can think of.
It's a real shame because it means ACL usage is not going to take off anywhere soon.
I doubt there is a good general purpose permission model that's more complex than Unix modes.
Collaboration on filesystems just doesn't work very well. It could work for many small groups if files had no users associated and everybody had just R and W bits for a whole repository.
For special problems there are specialized solutions. For example distributed models like git, or complex client-server solutions.
Your wording, speaking of repositories and git, bespeaks a too-narrow idea of what ACLs can be used for. Aside from all of the examples that one can glean from Windows NT, from window stations to the trusted installer, there are things like using ACLs to govern access to in-filesystem control/status APIs, or using them to limit the things that a subverted logging daemon could possibly do.
umask: A user with a umask of 0220 can write to the shared directory but no other group members will be able to read setgid: A user creating a directory with the setgid bit dropped will end up losing the shared group ownership and use their default group instead, again making it impossible for other group members to read and write data
ACLs such as NFSv4 ACLs include inherited ACEs for files and directories, so that the permissions set on newly created files and directories are controlled. Since these extended permissions are outside the scope of the standard group, setgid and umask settings, you have a system which is transparent to all users--once they are set up, no end user needs to care about them.
If I had such a case, the ACL solution could easily be emulated by putting such a directory below another directory which is accessible only to readers and writers. (Yes, files would need mode 664 and the right group. Not saying it's not a kludge, but you can tell people to fix the modes, or write a script which does that. It's a minor pain given that this case seems to be really rare).
Contrast that to ACLs on Windows. What I do know is it has Apache-insane chains of "access" and "deny". I've messed up permissions more than once, as only user of a system. Allegedly confirming to view another user's files in the explorer silently causes destructive changes to all the files in there (that must be why it takes ages). The mechanism is more complicated, so harder to debug, and it's harder to understand where's the problem when things don't work as expected.
Anyways, when things get complicated as you described, doesn't that indicate that a proper VCS should be put in place? Multiple editors is crying for problems. It's easy enough to just put these files in a git repo and be done. The traditional hierarchical file system is convenient for simple (i.e. most) uses, but in the end it's just an object graph with a restriction to avoid loops to achieve some amount of "hierarchical". That object graph model isn't really made for treating subtrees of files uniformly. It doesn't have transactions. It's not good for anything much except helping to organizing a bunch of objects in a DAG.
How do inherited ACLs play with files that are linked from multiple directories?
Regarding using a "proper VCS", it depends upon what kind of data you're dealing with. We use git for all our code, but git has zero permissions associated with it other than the execute bit. We use the filesystem for data files; we have many terabytes of uncurated and curated data for integration testing and other purposes. Some people have write access to curate it; some accounts need read access (CI slaves, developers); other accounts are not allowed to read it (some is public, some is under NDA, and other restrictions apply).
I certainly agree that on Windows this can look horrific (and is horrific). However, all I'm suggesting for this situation on Unix is to add a single group access control entry, and optionally file+directory inherited entries to ensure their propagation. You add them once at the root, and then that's it; they are set and done. Since you are using just one group permission, you're not getting a huge explosion of entries, and it will remain clean and understandable. I've seen repeated problems with the basic Unix perms over a five year period here which require repeated action by the admins or guilty parties to fix them up, plus the issue with access via Samba or NFS on client systems accessing the data. That adds up to a maintenance burden which can now be eliminated entirely, making life easier for everyone concerned and the infrastructure is more robust as well. None of the end users even need to be aware of the existence of ACLs; unless they manually screw with the automatically set ACEs, it will just work. As with everything there's a cost/benefit to consider; there is a cost, but ACLs are not universally bad.
There is "dynamic inheritance".
> Links won't affect anything--you can't link directories.
You can link files from multiple directories, leading to the question which is the parent from which permissions should be inherited.
> We use git for all our code, but git has zero permissions associated with it other than the execute bit.
Git is just an object model. It doesn't have an authorization scheme, and this is the advantage. It's easy to add authorization schemes that are truly repository-wide and match the requirements. You can write authorization logic which takes a (PERSON x REPO x COMMITBIT) table to handle pushes and pulls. Then for more complex requirements like groups, write a script which generates these per-person-per-repo bits from a per-group permission list and a group membership list - no actual need to code complex (and domain-specific) logic in the authorization layer. (If you have no proper authorization in place and don't want gitlab or gitolite, get in touch with me. It's easy to do it yourself, I even have a (some what over-engineered) solution "gitadmin" at github).
> I've seen repeated problems with the basic Unix perms over a five year period here which require repeated action by the admins or guilty parties to fix them up, plus the issue with access via Samba or NFS on client systems accessing the data.
I know these problems from my workplace, and my assumption (backed by minor experiences from personal use) is that ACLs only make this problem worse. With static inheritance you still have to fix up permissions. Dynamic inheritance is hard to debug. It's easier to just have a script (maybe cronjob) which fixes up permissions.
On Linux, ACL is the "facl" family of functions functions (and the set/getfacl programs). These supplement the traditional owner/group and mode bits. Essentially, it allows you to set a separate set of read/write/execute bits on a file for an arbitrary number of specific users or groups, rather than being limited to simply "owner", "group", "everyone-else". If anything is set beyond the normal owner/group/world, GNU `ls -l` indicates this with a "+" next to the normal mode bits. I'm unsure how much this changes for other kernels.
However, other systems support the more modern and featureful NFSv4 ACLs. NFSv4 ACLs are supported by the NFSv4 filesytem and also used by ZFS. They are part of the NFSv4 formal specification. On systems supporting ZFS (other than Linux), you get the full NFSv4 ACL support. Linux doesn't have VFS support for NFSv4 ACLs, and doesn't expose them even for NFSv4 mounts. In contrast, a FreeBSD mount of an NFSv4 filesystem served from ZFS exposes the full permissions model to the client. FreeBSD has a separate set of richer acl_* functions rather than the get/setfacl functions on Linux.
Linux:
% getfacl ~/.zshrc
getfacl: Removing leading '/' from absolute path names
# file: home/rleigh/.zshrc
# owner: rleigh
# group: rleigh
user::rw-
group::r--
other::r--
% getfacl ~/.zshrc
# file: /home/rleigh/.zshrc
# owner: rleigh
# group: rleigh
owner@:rw-p--aARWcCos:-------:allow
group@:r-----a-R-c--s:-------:allow
everyone@:r-----a-R-c--s:-------:allow
Not to nitpick, but: why would it need to do that? Nobody (in Joel Spolsky definition of nobody) cares about NFSv4. The only place where ACL matters for Linux users is Samba. And Samba works fine with Linux ACLs as it is.
This isn't about NFSv4 (the filesystem), it's about the rich permissions model it standardised which is now used by more than just NFS. It's used by ZFS, and it's used by the FreeBSD and Solaris VFS, and likely others as well. It's the only rich ACL model in real use today on open platforms, and being a superset of both POSIX.1e DRAFT and Windows ACLs, it's needed for full interoperability between platforms.
Samba doesn't "work fine" except for the simple case. Using it with groups and group permissions can be exceedingly painful. When I export a ZFS filesystem on FreeBSD over Samba, it exposes the full ACL model to the Windows client which is accessible and manipulable via the standard security properties as well as the command-line on the server or and NFSv4 clients.
When working with group permissions locally or over NFSv4 or CIFS, you aren't restricted to the pitiful group and setgid permissions offered by the standard UNIX permissions or even POSIX.1e ACLs. You can add an @group ACE detailing the group access permissions and their inheritance, or custom ones per user, which can make working on shared data much simpler. No more pain when someone with a broken umask adds something and strips off the group permissions, or they drop the setgid bit and the inheritance is lost, or they access it via samba and it sets the wrong group ownership or permissions. All of which I see regularly on shares exported from Linux. We often have to export the same share multiple times with different configuration to work around the limitations (read-only, group and group perms), where if it was using proper ACLs just one would work for all cases.
However, your first sentence is valid for many things, not just ACLs. For example, there are people (ehm, me) who value being able to have Kerberos tickets for multiple principals from multiple KDCs at the same time. This is something that the most popular OS (Windows) is not able to do - and nobody minds. Because for most people, being part of one domain is good enough.
With ACLs, I find it similar. For most people, the complexity is too high, the reasoning about them so complicated, so there's no benefit to have them available, they won't use them anyway. Also, in our case, we just have multiple groups at the root of samba share and that's it. It is good enough. So maybe it is yet another case of worse is better.