Why we aren't tempted to use ACLs on our Unix machines
utcc.utoronto.ca
utcc.utoronto.ca
I don't think the support here is too awful: given that it's what NFSv4 supports, it should be available to all clients. It doesn't help that the tools are crap on the Linux side--the POSIX.1e DRAFT ACLs are all they support last time I checked, and this dead non-standard should really just be replaced by the NFSv4 model at this point. Not sure what ZFSOnLinux does to work around this shortcoming.
[1] Here's one on the network filesystem setup: https://utcc.utoronto.ca/~cks/space/blog/unix/NFSFutureDesir...
An inappropriately-recursive setfacl added additional read / exec rights to the key files in a user's .ssh directory, which caused SSH to bail-out without establishing a connection. Subtle to find, it was only the "+" suffixed on the ls -al output that gave the clue...
ACLs are very powerful for solving specific problems but as the blog-post points-out they can have all sorts of unexpected side-effects.
For other ways to completely baffle your users, have a play with file attributes:
The old (other, group, user) * (read, write, execute) unix model is much easier to use, and sufficient for the vast majority of uses.
Occasionally, there is a need for something that can be expressed by ACLs, but not by Unix permissions. In most deployments, it is so rare that people who are not aware with ACLs just find some other way to do it.
ACLs are not the end-all-be-all permission system either. I would really like a permission system that says "in this directory, everyone can create a file, but no one can create an .mp4 or .mp3 or executable file". ACLs can't do that.
Some 20 years ago, when I occasionally had to audit file system permissions, Unix ones were usually properly set up (every user has write access to their own stuff, read access to shared stuff, and no access to other's users stuff, with groups used to do exceptions), and NT systems were always a mess, with lots of unexpected permissions and wrongly set up ACLs because complexity.
The best setups were always Novell Netware with their "Trustee" security model, which makes it much easier to get what you want than either ACLs or Unix perms
Conceivably you could hack up a custom solution for this, where certain groups are tagged as "owned" by a user, and the user can run a setuid binary to add/remove members. Or do it via an authenticated web interface or something. Would require some careful design/testing to avoid being a security risk. There are more esoteric possible uses of ACLs this wouldn't solve, like giving certain users append-only permission to some files. But a way for users to manage their own groups would probably handle 90% of the likely uses of ACLs in this setting.
pi_account ALL= (root) groupadd course_*
pi_account ALL= (root) usermod -a -G course_* *
It's really not, in an even moderately-complex environment. What I've seen most often is that the "user" and "group" permissions get eaten up by other factors (e.g. the "user" is a service account), so the only permission that can meaningfully be altered is "other".
The result is that either all of the people who support whatever the app is doing have to be given sudo permissions as the service account (drastically reducing the value of any audit/logging), or access has to be controlled at the OS level in terms of who can log onto the system in the first place. In other words, band-aids to work around the limitations of the traditional Unix filesystem permission model.
Indeed, some pieces of software insist that the service user actually do everything, which is still supported with this model if the binaries are setuid with +x on owner and group but not other -- although, as you pointed out, auditing tends to suffer in this case.
Speaking of which -- what's your favorite auditing setup? I need to set one up soon, I've been using auditd but it feels cumbersome.
The challenge I've run into with the group permission is that because there's only the owning group for the file/directory, there are basically two options:
1 - Leave the content owned by the primary group of the service account which also owns the file, and make support staff members of that group. This has the side effect of giving those support personnel access to just about everything else that group can get to, even if they don't need it.
2 - Create a new group that's just for delegating permissions for whatever content needs to be secured, and add both the service account and the users. This is analogous to using the new group as a quasi-ACL, IMO. It works, but quickly leads to group sprawl, and most of the Unix/Linux admins I've worked with are loathe to do it for this reason.
A secondary challenge with #2 is that larger organizations will usually have group membership controlled by some sort of administrative team. So getting the group membership changed is a much bigger headache than the filesystem object owner modifying the ACL on their own content.
NFS = Network File System
since sysadmins never bother defining anything in their articles.
You don't get to pick your audience on the internet and IAA strikes me as a sensible thing to do.
The tone of this comment's grandparent is certainly less confrontational than the tone of it's parent. And whatever offence there is in the grandparent hardly rises to the level internet outrage.
the sysadmin is a subset of hacker, a culture proud of its autodidactic tradition. and the spirit of the internet is to share useful information once you've learned it. it is totally appropriate to come to this website and post that you were interested in the subject of security in networked file systems, didn't know what the acronyms meant, and here's that information if anyone else wanted to know.
it is extremely important to learn how to learn. and i am genuinely curious about this apparent expectation that literature in a highly technical field should have a glossary everywhere. would you expect a blog about routers to always explain what TCP/IP stands for?
The present pop psychology pathologizing of parent poster's purpose hardly makes the proposed proposition of "you"'s previous use as primarily a literary device particularly plausible. But at least there is no pretence that it was primarily a charitable or polite reading.
It is not being used here as an acronym for the general concept of network file systems. It's a specific filesystem/protocol named "NFS", originally the Sun Network Filesystem.
getfacl --tabular ./*
For some reason simple * would not work.