4 ms·

One of the complaints brought up - the 16 bit group/uid seems to have been fixed quite nicely in modern linux systems by adding an additional 16 bit s to each.

by primis 5y ago

One of the complaints brought up - the 16 bit group/uid seems to have been fixed quite nicely in modern linux systems by adding an additional 16 bit s to each. It seems these problems aren't "unfixable" after all

Macha 5y ago
Proper ACLs exist on Linux these days as an alternative to user/group permissioning as well for use cases which call for a more powerful system.
- bombcar 5y ago
  The "systematic" part of things is relatively easy to handle (as the code can be made to handle anything complex) - it's the "user" interface that is harder. A user with root access wants to give access to a given file/directory to a user - this needs to be made easy to do successfully and securely. Too many times I've seen entire web directories 777 because they just wanted it to work. Commands providing "why user X can't access Y" and recommended solutions can help.
  - samf 5y ago
    Yes, this is a major problem when you introduce ACLs into unix-like systems. A comment in the article mentions the "Richacl" work. A key problem with this work was that even "chmod 777" might not get you out of a situation where an ACL was denying access. It's been over ten years since I've been involved in this; it might have changed. The POSIX draft ACLs had the same problem, where a chmod might not grant you the permission that you're asking for. Back when Solaris implemented POSIX draft ACLs, they needed to change many user-level interfaces (e.g., the chmod command and the ftp daemon) to have a chmod request work the way end users expected.
- devchix 5y ago
  Have you worked with setfacl(1), getfacl(1) recently? The agony they inflict makes me want to die. Do you need log dirs read by a non-root logreader? Are there nested subdirs? What are the defaults? Extra crispy boss-mode: is SELinux on? I think the extended ACLs have taken us further into the weeds, and I think the permission architecture needs to be rethink entirely. It was designed for shared university-type computing resources at a time when 30 profs and researchers shared dirs and commingle a set of files, and daemons are users with own places to keep things. No longer. The RBAC and inheritance model, I dunno, they may work correctly but they are so fiddly with so many knobs and intersections that you end up front-loading a huge amount of work; nobody wants to do that, nor have I seen it done correctly, with design and intent.
  - GauntletWizard 5y ago
    I'm actually fully behind the POSIX permissions model as a solution for this: If you have a group that all needs read/write, no big deal. If you have a group that needs to write and the world reads, no big deal. If you have a group that writes and another group that reads: No big deal, so long as you have a third group that's the union of both groups and can have a multi-level subdirectory (where a/ has 750 and a/b/ has 775). If you have groups that need to read and groups that need to write in a more complicated (or somehow path-specific) problem, you probably need a daemon or setuid program to moderate access, and that's okay. Happy to argue it or simply be told I'm wrong, but I've yet to encounter a not-insane permissions model that I couldn't solve with some "simple" nested groups (that in and of itself is a tooling problem, but a solvable one) and POSIX.
- trasz 5y ago
  Linux is probably the last major system not supporting NFSv4 ACLs. Windows (obviously), MacOS X, Solaris, FreeBSD - all those support them - for at least a decade now.
- p_l 5y ago
  POSIX ACLs were something even the POSIX group didn't want to publish and are horrible, horrible mess once you deal with ACLs beyond individual files. I spent some... long nights writing a program that ensured ACLs were appropriately applied in complex setup and automatically inherited by new files. It supported both NFSv4/ZFS format and POSIX ACLs... the former was essentially one line per ACL, the latters involved very racy "drop all", "apply again recursively in very specific order" for every change in ACLs.
mmcgaha 5y ago
The idea that having ownership and permission bits at the file level being a problem fixed by moving the permissions to the directory level completely hand waves over the fact that hard links exist in unix file systems. They need to think a little harder about that Mencken quote.
- wmanley 5y ago
  See the next article in the series "Ghosts of Unix past, part 4: High-maintenance designs"[1]. This specifically addresses how the existence of hard links is elegant in itself, but exports complexity to other parts of the system. [1]: https://lwn.net/Articles/416494/ https://lwn.net/Articles/416494/

by primis 5y ago

Macha 5y ago

Proper ACLs exist on Linux these days as an alternative to user/group permissioning as well for use cases which call for a more powerful system.

bombcar 5y ago
The "systematic" part of things is relatively easy to handle (as the code can be made to handle anything complex) - it's the "user" interface that is harder. A user with root access wants to give access to a given file/directory to a user - this needs to be made easy to do successfully and securely. Too many times I've seen entire web directories 777 because they just wanted it to work. Commands providing "why user X can't access Y" and recommended solutions can help.
- samf 5y ago
  Yes, this is a major problem when you introduce ACLs into unix-like systems. A comment in the article mentions the "Richacl" work. A key problem with this work was that even "chmod 777" might not get you out of a situation where an ACL was denying access. It's been over ten years since I've been involved in this; it might have changed. The POSIX draft ACLs had the same problem, where a chmod might not grant you the permission that you're asking for. Back when Solaris implemented POSIX draft ACLs, they needed to change many user-level interfaces (e.g., the chmod command and the ftp daemon) to have a chmod request work the way end users expected.
devchix 5y ago
Have you worked with setfacl(1), getfacl(1) recently? The agony they inflict makes me want to die. Do you need log dirs read by a non-root logreader? Are there nested subdirs? What are the defaults? Extra crispy boss-mode: is SELinux on? I think the extended ACLs have taken us further into the weeds, and I think the permission architecture needs to be rethink entirely. It was designed for shared university-type computing resources at a time when 30 profs and researchers shared dirs and commingle a set of files, and daemons are users with own places to keep things. No longer. The RBAC and inheritance model, I dunno, they may work correctly but they are so fiddly with so many knobs and intersections that you end up front-loading a huge amount of work; nobody wants to do that, nor have I seen it done correctly, with design and intent.
- GauntletWizard 5y ago
  I'm actually fully behind the POSIX permissions model as a solution for this: If you have a group that all needs read/write, no big deal. If you have a group that needs to write and the world reads, no big deal. If you have a group that writes and another group that reads: No big deal, so long as you have a third group that's the union of both groups and can have a multi-level subdirectory (where a/ has 750 and a/b/ has 775). If you have groups that need to read and groups that need to write in a more complicated (or somehow path-specific) problem, you probably need a daemon or setuid program to moderate access, and that's okay. Happy to argue it or simply be told I'm wrong, but I've yet to encounter a not-insane permissions model that I couldn't solve with some "simple" nested groups (that in and of itself is a tooling problem, but a solvable one) and POSIX.
trasz 5y ago
Linux is probably the last major system not supporting NFSv4 ACLs. Windows (obviously), MacOS X, Solaris, FreeBSD - all those support them - for at least a decade now.
p_l 5y ago
POSIX ACLs were something even the POSIX group didn't want to publish and are horrible, horrible mess once you deal with ACLs beyond individual files. I spent some... long nights writing a program that ensured ACLs were appropriately applied in complex setup and automatically inherited by new files. It supported both NFSv4/ZFS format and POSIX ACLs... the former was essentially one line per ACL, the latters involved very racy "drop all", "apply again recursively in very specific order" for every change in ACLs.

mmcgaha 5y ago

The idea that having ownership and permission bits at the file level being a problem fixed by moving the permissions to the directory level completely hand waves over the fact that hard links exist in unix file systems. They need to think a little harder about that Mencken quote.

wmanley 5y ago
See the next article in the series "Ghosts of Unix past, part 4: High-maintenance designs"[1]. This specifically addresses how the existence of hard links is elegant in itself, but exports complexity to other parts of the system. [1]: https://lwn.net/Articles/416494/ https://lwn.net/Articles/416494/