Slashdot Mirror
FreeBSD Access Control Lists
BSD Forums writes "The Unix permissions model has worked for decades due to its flexible simplicity. It's not the only approach, though. FreeBSD 5.0 supports Access Control Lists, which allow for more flexible permissions. Daniel Harris explains what ACLs can make easier."
Flexible systems solve more of the initial problem but tend to be harder to manage. (Pick your favorite example: Linux vs. Mac, C++ vs. Java, Civilization vs. Quake, ...) What I worried about back when I used ACLs was that roles can change over time. Yes, I have some directory that Bob should have access to. Two months from now, Alice joins Bob's group and takes over his duties, so she needs access. Can Bob grant that access? Now what happens when Bob transfers to a different group? Who's going to go around checking all files accessible by Bob to determine which of them were accessible by him because he's working on some particular project and which were accessible because he's a good buddy of mine? What if you forget to do this?
Keep it simple. If not for yourself, for your children, and your children's children.
-- Amit (overgeneralizing)Other operating systems, including UNIX, have had ACLs before Windows NT even existed and the concept was derided then as well. This is not a "Un*x vs Windows" argument. Please don't turn it into one.
The typical arguments against ACLs are:
The trick, as with all computing, is to weigh the benefits vs the costs. Sometimes you need ACLs and then it makes sense to introduce the extra complexity. Other times it makes no sense at all, so you dispense with them. For example, there's not much value in ACLs for an embedded UNIX with a single user (eg, a PDA). There's definitely a lot of value for ACLs with a multiuser UNIX or a UNIX fileserver. You need to decide when it makes sense to have ACLs and when to use UNIX ugo, not make blanket statements about one being better than the other.
> But Windows NT has had ACLs for some time now.
True, and they have features that POSIX ACL's don't, such as more granular access rights and categories like OWNER/CREATOR.
It also has this other charming feature: when you use the GUI, it sorts the ACL by name. And when you have global allow or deny privs on particular credentials, but specific other credentials that override them, they may work when you set them, then mysteriously not once you simply view them in the GUI, because the list has been reordered, and the first one wins. This sort of thing drives NT admins nuts. And there's no sign of it being fixed.
I've finally had it: until slashdot gets article moderation, I am not coming back.
Let's face it. We've all known that the classical Unix security model (uid/gid) was not fine-grained enough for modern usage. But the problem has always been that the alternatives were complicated. That is the standard argument against ACL's. The reality is that this is a messy problem that doesn't have any elegant solutions. If there was a simple solution, someone would have found it by now. So, the best thing to do is to implement the current solution (ACL's) and make it work as smoothly as possible.
I'm definitely not a Microsoft fan. But one quality of Microsoft that I admire is that they are not afraid to move forward in situations where there are no clean solutions. By contrast, the Unix community often gets bogged down in such situation and is unable to make progress for long periods of time. I realize this is somewhat unfair, since Microsoft developers get paid to do this grunt work. But if Linux/*BSD wants to compete directly with Microsft (as many advocates claim), it must do the same.