lkml.org 
[lkml]   [1999]   [Feb]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: linux capabilities and ACLs
    On Thu, 4 Feb 1999, Albert D. Cahalan wrote:
    > Good. POSIX ACLs are awful. Somebody stop the ext2 developers before
    > it is too late. With a tiny bit of thought, it should be obvious
    > that the inheritance system is broken. ACL systems that are much better
    > include those of NT, Netware, Digital Unix...

    I think the TOPS-10 system was conceptually much better, although the
    implementation suffered from problems (mainly because it was a gross
    hack). The basic idea is that the ACLs are *not* stored as some sort
    of extended attribute of the files, like they are on most other systems.
    Instead, the ACLs for a user's files are in a single file (I don't recall
    if TOPS-10 actually did one file per user, or one per directory per user).

    Basically, this file contains a list of descriptions of allowed and
    non-allowed accesses, with wildcarding allowed. You could base things
    on the name of the file (including path), the user and group of the
    person trying the access, the type of accesses they were requesting,
    and what program was trying the access.

    The system only checked the access file if the access was not otherwise
    allowed.

    This doesn't conveniently do everything convention "ACL's as extended
    attributes" do, but if you are reasonably organized in how you store
    your files (e.g., you tend to put things with the same desired access
    rules in the same directory), it works great.

    There are two big advantages compared to the "ACL's as extended
    attributes" approach.

    1. No modification is needed to the format of any filesystem to
    support this.

    2. No modification is needed to existing utilities.

    On TOPS-10, the access file was just a text file, and the wildcarding
    was the same kind used for filename matching. I think on a Linux
    implementation, I'd prefer full regular expressions, and probably
    for speed have the text file compiled into a binary file.

    I think this kind of system should be considered for Linux. I can see
    some problems with hard links, but it might be a nice way to provide
    most of the benefits of ACLs with almost none of the disadvantages
    of the usual approach. If a Linux implementation kept the TOPS-10
    behaviour of only checking the access file on accesses that would
    otherwise fail, then there should be minimal backward compatibility
    issues (the only thing that comes to mind offhand would be programs
    that try to figure out on their own if something is allowed, rather
    than just trying and letting the kernel tell them).

    --Tim Smith

    ps: the big problem with the TOPS-10 implementation was that the access
    check was done by a daemon outside the kernel. When an access failed,
    the kernel send a message to FILDAE describing the request, and FILDAE
    told the kernel if it was to be allowed. People manage to find and
    exploit bugs in the communication between FILDAE and the kernel to get
    them out of sync.


    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:50    [W:5.979 / U:0.412 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site