3 ms·
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 the
by 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 agoI'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.