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."
But Windows NT has had ACLs for some time now.
A lot of people have derided the concept.
But as far as I can see, they are a complete superset of the Un*x system.
It's pretty hard to argue that it's not as good.
Discuss.
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)I had a directory that I wanted 777 for all but user www. The solution was simple with ACL's; it eliminated the need for adding a new group for one measly dir.
Go ACL's!
It's not like FreeBSD is the first to have ACLs. Solaris and Linux both support them as well.
One thing I like under Solaris ACLs is you can set a "default" permission. I always have my default umask set to 027, but I do some collaborative work in some shared directories and it's nice to be able to force any files created in that directory to be writeable by the group. ACLs on Solaris completely ignore the umask.
Under Linux, however, the ACLs work with the umask. I can set default permissions for a directory to be group read-only and files created by someone with a 007 umask will be set to read-only, but I can't do the opposite.
I believe Linux is doing the POSIXly correct thing, but I don't find it very useful.
-- Don't Tase me, bro!
Isn't it time Slashdot make use of ACL's to prevent the "*BSD is dying trolls" ?
Netware ACLs were the best and simplest to work with. I still miss them. For those with no Netware experience, directories had the following attributes:
/usr/local/foobar/foo/bar but am explicitely excluded from rights to foobar/ and foo/, I can still get to my directory and only see just the directories I need to navigate the file system.
Read, Write, Create, Erase, Modify, File scan (see directory contents), Access control (ability to change attributes for these properties for yourself or others), and Supervisory which enabled turning any of these bits on or off regardless of their status.
IIRC, RF was the default permission. Subdirectories always inhereited the permissions of their parents, although the above permissions could be selectively blocked from inheritance.
My favorite feature (which if 2K had would make life lots easier), was directory traversal rights were automatic. If I as a user have RWCEMF rights to directory BAR located in directory tree
Systems without traversal rights like this require some pretty convoluted logic to make them work, like home folders in Win2k. You need to make HOME readable to everyone so it can be mounted and people can find their home directories, but each user home directory needs inheritance blocked and specific user rights assigned. In Netware rights, you just grant the user rights to their directory, admin rights to HOME, and inheritance and directory traversal make it work.
I hope BSDs ACLs include automatic minimal traversal rights and inheritance.
I have no idea about Windows NT, but "real" operating systems of yore such as Honeywell's ancient GCOS (usually referred to as God's Chosen Operating System) back in the late 70s and early 80s, PRIME's PRIMOS (1980s) and Data General's AOS/VS (1980s) and AOS/VS2 (early 1990s) all had effective implementations of ACLs. Nothing new here.
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.
95% of the time they just increase overhead for the admins, but for that 5% that you really NEED them for, they are a godsend...
---- Booth was a patriot ----