4 ms·

Linux's refusal to adopt RichACLs/NFSv4 ACLs forever perplexes me, and maybe some day I'll be pleasantly surprised when they do show up. A complete superset of

• wmf 4y ago
  How many people use ACLs?
  • pinewurst 4y ago
    In the real world only a small minority even use NFSv4 and that mostly for the figleaf of encryption via (yuck!) Kerberos. As a (too) long time storage industry person, I have hard numbers on this.
    • pmontra 4y ago
      AWS's EFS is mounted with NFSv4 on Linux instances. Had to fight against race conditions between clients recently (per client directory caches,) but that's a feature of NFS, not specifically v4.
    • mort96 4y ago
      But quite a lot of people in the real world use NTFS.
  • chungy 4y ago
    It's primarily a corporate-level thing, but just as Windows has a strong set of ACLs that people at home ignore, it could be the same scenario on Linux.
  • asveikau 4y ago
    This is a Yogi Berra type comment. "ACLs aren't supported. Nobody uses them."
    • wmf 4y ago
      Not really. Linux supports "old" posix ACLs and chungy is complaining that it doesn't support "new" rich ACLs. My point is why bother upgrading a feature that no one uses.
      • chungy 4y ago
        I think "no one" is a fairly tall claim: They are well-used on all the operating systems that do support them. Mind also, "old POSIX ACLs" came from a POSIX draft: they never made it into POSIX. While being an extremely simple expansion of the Unix modes, they are only ever additive and do not support fine-grained permissions that NFSv4 allows for. They're sometimes better than the standard mode bits, but they very often come up short of being useful in the real world.
  • nerdponx 4y ago
    I have used them to set up a group-readable/writable directory to ensure that all subdirectories remain so.
  • cesarb 4y ago
    > How many people use ACLs? Everyone who uses systemd. Try it yourself: do a getfacl on the files inside /var/log/journal on a system with persistent logging enabled (if it's disabled, these files will be at /run/log/journal instead).
• throw0101c 4y ago
  > Linux's refusal to adopt RichACLs/NFSv4 ACLs forever perplexes me, and maybe some day I'll be pleasantly surprised when they do show up. As someone who has had to deal with NFSv4-styles ACLs (on an Isilon server handling Linux HPC clients): they can get really messy, really quickly (especially the inheritance aspect of them).
• WhyNotHugo 4y ago
  I've never found any limitations to Linux's ACL. I'm not saying your use case is invalid; I'm actually expressing sincere curiosity: what do NFSv4 ACLs bring to the table and what problems does it solve?
  • chungy 4y ago
    It's a different enough system, I think it's worth restating what Linux's present ACLs are, which were based on a POSIX draft: They are additive permissions that model the Unix mode bits. Per-user and per-group, you can add read, write, and execute permissions that they otherwise would not have. NFSv4 ACLs are far more powerful, modeled after NTFS ACLs (a proper superset, with an added two permission types). In network environments (where you'd use them anyway), they can assign access control entries (ACE) with Security IDs (SIDs), generally more stable and consistent across a network than ad-hoc Unix user IDs/group IDs. Managing with UIDs/GIDs is still possible, too. They add both allow and deny permissions to ACLs; if you want to deny "fred" from reading a file, you can make a deny entry for "fred" specifically. The fine-grained permissions you can get from NFSv4 ACLs: READ_DATA, LIST_DIRECTORY, WRITE_DATA, ADD_FILE, APPEND_DATA, ADD_SUBDIRECTORY, READ_NAMED_ATTRS, WRITE_NAMED_ATTRS, EXECUTE, DELETE_CHILD, READ_ATTRIBUTES, WRITE_ATTRIBUTES, DELETE, READ_ACL, WRITE_ACL, WRITE_OWNER, SYNCHRONIZE. READ_DATA, WRITE_DATA, EXECUTE are equivalent to the read/write/execute Unix mode bits. The two expanded features I find I use most frequently are blocking the deletion of files and making them append-only.