[lkml]   [2002]   [Oct]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: What's left over.
    [ Cc: trimmed ]

    john stultz wrote:
    > groups for each project, I have no clue how anyone would be able to
    > handle the (unix)group management required. ACLs let the users
    > themselves manage what people got what access to their data.

    Note that POSIX ACLs don't seem to solve this either: they only
    let you control access in terms of existing users or groups.

    IMHO, this is one of the standard pitfalls of ACLs: if they don't
    let you aggregate information, you quickly end up with huge ACLs
    hanging off every file, and each of those ACLs wants to be
    carefully maintained. I've seen a lot of this in my VMS days.
    (Unix is a bit better, because you can control access at a
    directory level, while VMS needs the ACL on each file, because
    you can open files directly by VMS' equivalent to an inode
    number, without traversing the directory hierarchy. Of course,
    many users didn't know that :-)

    To make ACLs truly scalable, it would be nice to be able to
    express permissions in terms of access to other filesystem
    objects. E.g. "everybody who can read file ~me/acls/my_friends
    can write the directory on which this ACE hangs". This should
    work like a symlink, i.e. if I add new friends to my_friends, I
    don't have to update all my ACLs.

    - Werner

    / Werner Almesberger, Buenos Aires, Argentina /
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:30    [W:0.035 / U:25.924 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site