Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
BSD Operating Systems

FreeBSD Access Control Lists 108

Posted by michael from the chmod-777-much-easier dept.
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."
This discussion has been archived. No new comments can be posted.

FreeBSD Access Control Lists More

FreeBSD Access Control Lists

Comments Filter:

  • Now correct me if I'm wrong... (Score:3, Interesting)

    by Ataru ( 50540 ) on Saturday August 16, 2003 @05:59PM (#6714290)
    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.

    • Re:Now correct me if I'm wrong... (Score:5, Insightful)

      by nathanh ( 1214 ) on Saturday August 16, 2003 @06:55PM (#6714509) Homepage
      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.

    • Netware ACLs were best ever (Score:4, Informative)

      by swb ( 14022 ) on Sunday August 17, 2003 @07:38AM (#6716281)
      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:

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

      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.
      • As far as I can see, the ACLs in FreeBSD/UFS2 (following the POSIX.1e proposal) just know the traditional read-write-execute/search permissions, only with more fine-grained possibilities to assign these rights to users and groups. However, the FreeBSD implementation seems to be flexible enough to support additional flags - in fact, the acl(3) [freebsd.org] manpage explicitly mentions nonportable functions for Netware style ACLs (and some others, like NTFS). I have no idea how to actually use that, however.
        • More fine-grained rights are nice, but they're probably not necessary, since you can pretty easily roll Netware's WCEM into unix W.

          What really makes the magic IMHO is inheritance and dynamic traversal rights (on-demand X right). You can make a sensible rights policy with RWX, but without traversal you end up doing some crazy stuff to make it work.

    • Re:Now correct me if I'm wrong... (Score:4, Insightful)

      by scrytch ( 9198 ) <chuck@myrealbox.com> on Sunday August 17, 2003 @10:21AM (#6716783)
      > 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.

    • But Windows NT has had ACLs for some time now.

      And Windows permissions are the single biggest pain in the ass of any permission system ever created.

      Want to add a new user to this folder and all sub-folders? Well TOO DAMN BAD! You almost always need to add the user to every single sub-folder manually. Of course, there are situations where the permission will filter down, but they are rare, and in that case, you haven't been using ACL's benefits, so you might as well have been using unix permissions. By

  • Management cost vs. flexibility (Score:5, Insightful)

    by Amit J. Patel ( 14049 ) <amitp@cs.stanford.edu> on Saturday August 16, 2003 @06:20PM (#6714370) Homepage Journal

    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 [stanford.edu] (overgeneralizing)

    • Re:Management cost vs. flexibility (Score:5, Interesting)

      by Paul Jakma ( 2677 ) on Saturday August 16, 2003 @06:36PM (#6714441) Homepage Journal
      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.
    • Roles can change over time, that is true.
      Under Un*x as far as I can see you have this "group" attribute that means that if you are a member of any group authorised to fuck with the file, you can fuck with the file.
      I'm sorry, this might have worked back in the day, when everyone was a beardy hacker, but nowadays it is asking for a bum-raping.
      ACLs, being a superset of the almost nothingness of Group Permissions, do have the disadvantage of being slightly more complicated. But then, the simpler system is obvi

  • ACL's rock. (Score:4, Interesting)

    by craig2787 ( 533589 ) on Saturday August 16, 2003 @07:48PM (#6714673) Journal
    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!
    • You don't need ACLs in the OS for that.
      You need an ACL veneer over user/group
      permissions that dynamically allocates a
      new group as required in order to fulfill
      the constraints you specify.

      ACLs are one honking big bird to swallow
      in order to take care of the fly you
      swallowed earlier. I don't know why you
      swallowed the fly.
      • I completely do not understand your post. I'm not even going to paste fragments to clarify, because I'd be pasting the whole thing. ACLs are cool beans, ok? Just leave it be, you'll be alright.

  • Default permissions (Score:4, Interesting)

    by Col. Klink (retired) ( 11632 ) on Saturday August 16, 2003 @08:46PM (#6714877)
    It's not like FreeBSD is the first to have ACLs. Solaris and Linux [debian.org] 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.
    • Are you using ACLs on XFS or another filesystem? I believe the XFS ACL implementation does support a default ACL, atleast in 2.4. With all the integration in 2.6 I'm not sure if that option survived.
      • I'm using ACLs under ext3. It supports "default" ACLs, just not the same way Solaris does. Actually, the Solaris 2.6 man page for setfacl says:

        If a file is created in a directory that contains default ACL entries, the newly created file will have permissions generated according to the intersection of umask(1), the default ACL entries, and the permissions requested at creation time.

        However, the setfacl man page under Solaris 9 say:

        The umask(1) will not b

  • Slashdot ACLs ? (Score:4, Funny)

    by noselasd ( 594905 ) on Sunday August 17, 2003 @04:33AM (#6715954)
    Isn't it time Slashdot make use of ACL's to prevent the "*BSD is dying trolls" ?

  • Unix needs ACL's (Score:4, Insightful)

    by big-magic ( 695949 ) on Sunday August 17, 2003 @03:16PM (#6718318)
    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.

    • Re:Unix needs ACL's (Score:1, Insightful)

      by Anonymous Coward
      I'm definitely not a Microsoft fan.

      And you don't need to be one to know that ACL's have a VMS history long before Microsoft added them.
      • I wasn't implying that Microsoft created the idea. ACL's are not the only situation where Micrsoft has forged ahead when there is no simple solution (while the Unix developers are left behind arguing about the "right" solution). As a matter of fact, there is probably lot of things the Unix community could learn by taking a second look at the details of VMS, OS/360, and other "old" technology. In particular, I've always thought we had a lot more to learn from the mainframe world.

        • "ACL's are not the only situation where Micrsoft has forged ahead..."

          If you consider what MS has for their ACL's as "forged ahead" then you are mistaken. There is nothing intuative or easy about Microsoft's maze of file permissions and layers of confusion.

    • _UNIX_ has had ACLs for a decade now (Solaris, HPUX, AIX, IRIX, etc). It's only the open source unix offshots like Linux or *BSD are getting them too only now.
  • Good Lord, there are more -1 posts on this article, than 0-5 posts.

    So many losers so few BSD's articles.

  • ACL's . .Good and Bad (Score:4, Interesting)

    by nurb432 ( 527695 ) on Monday August 18, 2003 @03:56PM (#6726220) Homepage Journal
    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...
  • oops, I mouse-o'ed while moderating. This post exists only to cancel that moderation.

  • I was using ACLs long before I began using FreeBSD and I've reduced my explanation of ACLs to the uninitiated to the following dialogue:

    Mike: "My mama didn't raise no fool!"
    Bob: "So who raised you, then?"

    Show me a shorter explanation of ACLs and I will post a troll about Linux. Oh, wait, this was it.

Slashdot Top Deals

"All the people are so happy now, their heads are caving in. I'm glad they are a snowman with protective rubber skin" -- They Might Be Giants

Close