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

6 of 108 comments (clear)

  1. Management cost vs. flexibility by Amit+J.+Patel · · Score: 4, Insightful

    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)
    1. Re:Management cost vs. flexibility by Paul+Jakma · · Score: 4, Interesting

      Well, the answer is to assign the permission to a group, not to Bob directly. But, drat, then you are back to using groups. :)

      The prime problem which ACLs solve or rather work-around, is that users:

      - have no way to specify their own collection of users (they have to ask the admin to create a group)

      AND

      - a user can not chgrp a file to any group of which they are not a member (security)

      ACLs provide normal users a means to assign permissions to files by arbitrary users, and (iirc) arbitrary groups. But they are, as you point out, a management nightmare - while being a feature very few people actually need.

      --
      I use Friend/Foe + mod-point modifiers as a karma/reputation system.
  2. Re:Now correct me if I'm wrong... by nathanh · · Score: 5, Insightful
    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.

    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:

    • ACLs add complexity to the filesystem code; making the filesystem slower, buggier, harder to write and more difficult to prove.
    • ACLs add an administrative overhead to the system. In a nutshell, ACLs can get messy very quickly. Very hard to debug certain problems.
    • ACLs can remove rights from accounts that actually need them. Typical problem is removing read-rights from the backup account.
    • ACLs require more complex userspace tools. This makes userspace tools bloated, potentially buggier and harder to use.

    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.

  3. Re:Now correct me if I'm wrong... by Przepla · · Score: 4, Informative
    Typical problem is removing read-rights from the backup account.
    Well in FreeBSD that is not a problem, since operator account was designed to do backups. This user has a read-only right to any filesystem. You have to use root account to set no-dump flag however.
    --
    When in doubt, go to the library. - Ron Weasley in Harry Potter and the Chamber of Secrets
  4. ACL's rock. by craig2787 · · Score: 4, Interesting

    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!

  5. Unix needs ACL's by big-magic · · Score: 4, Insightful

    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.