9 ms·

Why we aren't tempted to use ACLs on our Unix machines

34 points by mjn 11y ago

dingaling 11y ago
Ha, I've literally just finished debugging an SSH connection failure which turned-out to be caused by ACLs! 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.
- twic 11y ago
  The reason their side-effects are unexpected is not that ACLs are intrinsically weird, it's that very few people have familiarity with day-to-day use of ACLs on Unix. The reason that very few people have familiarity with day-to-day use of ACLs on Unix is that very few people use them. The reason that very people use them is because very few people are familiar with them. It's a bit of a Catch-22. For other ways to completely baffle your users, have a play with file attributes: http://linux.die.net/man/1/chattr http://linux.die.net/man/1/chattr
  - walshemj 11y ago
    Are ACL's so new for Linux? I remember using them on Primes back in the 80's
  - beagle3 11y ago
    ACLs are, for the most part, unneeded. 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
    - mjn 11y ago
      Since he's sysadmin in a university computer-science department (and going by the first paragraph of this post), I think group-type sharing is the specific use-case that the post author might be hypothetically tempted to solve using ACLs. Unix groups work for this but require the sysadmin to be involved every time you want a group created, users added/removed from the group, etc. It'd be nice in some cases if a regular user, say the PI of a project or the instructor of a course, could manage their own sharing permissions, without having to open support tickets every time they need a group created or modified. 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.
      - icebraining 11y ago
        You can use sudo for that, by allowing certain commands to be run by the PI, eg.: pi_account ALL= (root) groupadd course_* pi_account ALL= (root) usermod -a -G course_* * This would allow the PI to create groups with a certain prefix, and to add users to it.
    - blincoln 11y ago
      "The old (other, group, user) * (read, write, execute) unix model is [...] sufficient for the vast majority of uses." 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.
rleigh 11y ago
I am tempted and have started to use ACLs. Once you've got a ZFS filesystem (in my case, on FreeBSD like the author), you have full NFSv4 ACL support. If you export that over NFSv4, those ACLs are visible to all client systems. And if you export it over Samba, they are visible to Windows clients as well. 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.
- mjn 11y ago
  I believe the author's current setup is running ZFS on Illumos (specifically OmniOS), with volumes exported over NFSv3 and Samba. It's not mentioned in this post, but some of the older ones talk about it [1]. The comment about FreeBSD was worrying that if they started relying on ACLs now, and later switched their fileservers to NFS-on-ZFS-on-FreeBSD instead, they might end up with incompatibilities in the ACL models. [1] Here's one on the network filesystem setup: https://utcc.utoronto.ca/~cks/space/blog/unix/NFSFutureDesire https://utcc.utoronto.ca/~cks/space/blog/unix/NFSFutureDesir...
vortico 11y ago
ACL = Access Control Lists NFS = Network File System since sysadmins never bother defining anything in their articles.
- dvanduzer 11y ago
  why on earth would you expect a sysadmin to break those out? both acronyms have a pretty high usage saturation level. if you don't know these acronyms, a sysadmin isn't doing you a favor by telling the reader in a blog post about security features.
  - papaf 11y ago
    In several style guides I have seen, both in academia and journalism you always Introduce An Acronynm (IAA) before using it. You don't get to pick your audience on the internet and IAA strikes me as a sensible thing to do.
    - zeckalpha 11y ago
      Particularly since it's not dead print, you can have hovertext or a link to the expanded text without it taking up more space.
  - brudgers 11y ago
    I take the purpose of the comment as to inform HN'ers who aren't system administrators. To the degree it is a literary criticism, it lets the article and its author off the hook by classifying the style as typical of the genre. Again, I take this as informative since the lack of definitions in the article supports the claim. 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.
    - dvanduzer 11y ago
      speaking to "you" rather than throwing vague shade at the group of all sysadmins is merely direct, not confrontational. it is not an expression of outrage to point out how weirdly passive aggressive the remark was. 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?
digi_owl 11y ago
maybe i am using older tools here, but i found that getting a ls -l like readout of all the acls of a directory was a right pain.
- justin66 11y ago
  No, that's a pretty legit concern. There is basically no way to take a list of files with varying ACLs and display their permissions in a manner as condensed as ls -l. There is potentially a lot more information to put up onto the screen.
  - digi_owl 11y ago
    Abused the syntax some more, and found what i wanted if i used: getfacl --tabular ./* For some reason simple * would not work.

34 points by mjn 11y ago

Ha, I've literally just finished debugging an SSH connection failure which turned-out to be caused by ACLs! 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.

twic 11y ago
The reason their side-effects are unexpected is not that ACLs are intrinsically weird, it's that very few people have familiarity with day-to-day use of ACLs on Unix. The reason that very few people have familiarity with day-to-day use of ACLs on Unix is that very few people use them. The reason that very people use them is because very few people are familiar with them. It's a bit of a Catch-22. For other ways to completely baffle your users, have a play with file attributes: http://linux.die.net/man/1/chattr http://linux.die.net/man/1/chattr
- walshemj 11y ago
  Are ACL's so new for Linux? I remember using them on Primes back in the 80's
- beagle3 11y ago
  ACLs are, for the most part, unneeded. 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
  - mjn 11y ago
    Since he's sysadmin in a university computer-science department (and going by the first paragraph of this post), I think group-type sharing is the specific use-case that the post author might be hypothetically tempted to solve using ACLs. Unix groups work for this but require the sysadmin to be involved every time you want a group created, users added/removed from the group, etc. It'd be nice in some cases if a regular user, say the PI of a project or the instructor of a course, could manage their own sharing permissions, without having to open support tickets every time they need a group created or modified. 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.
    - icebraining 11y ago
      You can use sudo for that, by allowing certain commands to be run by the PI, eg.: pi_account ALL= (root) groupadd course_* pi_account ALL= (root) usermod -a -G course_* * This would allow the PI to create groups with a certain prefix, and to add users to it.
  - blincoln 11y ago
    "The old (other, group, user) * (read, write, execute) unix model is [...] sufficient for the vast majority of uses." 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.

rleigh 11y ago

I am tempted and have started to use ACLs. Once you've got a ZFS filesystem (in my case, on FreeBSD like the author), you have full NFSv4 ACL support. If you export that over NFSv4, those ACLs are visible to all client systems. And if you export it over Samba, they are visible to Windows clients as well. 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.

mjn 11y ago
I believe the author's current setup is running ZFS on Illumos (specifically OmniOS), with volumes exported over NFSv3 and Samba. It's not mentioned in this post, but some of the older ones talk about it [1]. The comment about FreeBSD was worrying that if they started relying on ACLs now, and later switched their fileservers to NFS-on-ZFS-on-FreeBSD instead, they might end up with incompatibilities in the ACL models. [1] Here's one on the network filesystem setup: https://utcc.utoronto.ca/~cks/space/blog/unix/NFSFutureDesire https://utcc.utoronto.ca/~cks/space/blog/unix/NFSFutureDesir...

vortico 11y ago

ACL = Access Control Lists NFS = Network File System since sysadmins never bother defining anything in their articles.

dvanduzer 11y ago
why on earth would you expect a sysadmin to break those out? both acronyms have a pretty high usage saturation level. if you don't know these acronyms, a sysadmin isn't doing you a favor by telling the reader in a blog post about security features.
- papaf 11y ago
  In several style guides I have seen, both in academia and journalism you always Introduce An Acronynm (IAA) before using it. You don't get to pick your audience on the internet and IAA strikes me as a sensible thing to do.
  - zeckalpha 11y ago
    Particularly since it's not dead print, you can have hovertext or a link to the expanded text without it taking up more space.
- brudgers 11y ago
  I take the purpose of the comment as to inform HN'ers who aren't system administrators. To the degree it is a literary criticism, it lets the article and its author off the hook by classifying the style as typical of the genre. Again, I take this as informative since the lack of definitions in the article supports the claim. 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.
  - dvanduzer 11y ago
    speaking to "you" rather than throwing vague shade at the group of all sysadmins is merely direct, not confrontational. it is not an expression of outrage to point out how weirdly passive aggressive the remark was. 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?

digi_owl 11y ago

maybe i am using older tools here, but i found that getting a ls -l like readout of all the acls of a directory was a right pain.

justin66 11y ago
No, that's a pretty legit concern. There is basically no way to take a list of files with varying ACLs and display their permissions in a manner as condensed as ls -l. There is potentially a lot more information to put up onto the screen.
- digi_owl 11y ago
  Abused the syntax some more, and found what i wanted if i used: getfacl --tabular ./* For some reason simple * would not work.