
Why we aren't tempted to use ACLs on our Unix machines - mjn
https://utcc.utoronto.ca/~cks/space/blog/sysadmin/NoACLTemptation
======
rleigh
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
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/NFSFutureDesir...](https://utcc.utoronto.ca/~cks/space/blog/unix/NFSFutureDesire)

------
dingaling
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
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)

~~~
beagle3
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

~~~
blincoln
"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.

~~~
beagle3
Could you describe what the "group" gets eaten by? In most cases I've seen,
the group works well as a permission set - e.g. "dialout" is for all users
allowed to use the dialer, "lp" for all those allowed to use the printer,
"audio" for those allowed to use the speaker, etc.

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.

~~~
blincoln
Filter this response based on my being a pen tester, not a Unix/Linux admin -
I'm much better at finding vulnerabilities and shortcomings than I am at
coming up with a really good solution to them :). That's also why I can't give
you a worthwhile answer about an auditing setup - I could tell you which ones
I'm not super fond of, but I've never run the auditing side of things on
Unix/Linux systems.

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.

------
vortico
ACL = Access Control Lists

NFS = Network File System

since sysadmins never bother defining anything in their articles.

~~~
dvanduzer
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
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
Particularly since it's not dead print, you can have hovertext or a link to
the expanded text without it taking up more space.

------
digi_owl
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
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
Abused the syntax some more, and found what i wanted if i used:

getfacl --tabular ./*

For some reason simple * would not work.

