[lkml]   [1999]   [Sep]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Ext3 filesystem info?
    > > Seems to me that some of this can be solved with a good generic
    > > ACL interface in the VFS. Various filesystems may then implement
    > > more or less of the VFS interface depending on what they support.
    > > Just as some filesystems implement links and some don't.
    > ACLs are just far too varied to be combined effectively in a single
    > API. We support distributed filesystems like AFS in which the server's
    > notion of who a user is is completely foreign to the kernel's uid/gid
    > scheme: how do you propose to identify such users when manipulating AFS
    > ACLs?

    I know I'm dumb, but what does really vary? The semantics or the rights
    you may grant/revoke in the ACL? If it is "only" the semantic design and
    implementation shouldn't be difficult.

    Could someone just list the types of ACL's spread around here _with_ the
    kind of files they allow ACL's on and the right's they allow to set?

    Yet I only know NT ACL's (sorry, I haven't worked with real OS'es which
    implement ACL's yet). They just seem to be a list of
    user/group-plus_minus_access-pairs, so I could imagine a quite simple
    ioctl-like syscall for that (it just returns ENOSYS for non-supported
    actions), please look at it before complaining :-)

    int sys_acl(fd_t fdint mode,...);

    where mode may be:
    ACL_LOCK makes write-to-acl-actions atomar (only owner and
    root may use it)
    addition Parameter: ACL_READ, ACL_WRITE, ACL_UNLOCK
    ACL_ACTIVATE additional Parameter: boolean to activate or deactivate
    the ACL of this file/directory
    ACL_GET additional Parameter: number of acl-entry or -1 to return
    amount of entries; pointer to a struct s_acl
    ACL_SET add.Param.: number of the entry and a struct s_acl
    ACL_ADD returns new number
    ACL_DELETE add.Param: number of the entry to be deleted
    ACL_MOVE add.Param: number of ACL to move, position to move to OR:
    ACL_XCHG Params as above, but exchanges these two

    struct s_acl{
    int ugid;/*UID or GID according to type*/
    int access;/*access bits: RWX (for some FS'es Append and others)*/

    Ok, now the task for everybody who _really_ knows ACL-systems: which FS'es
    could _not_ be covered by this syscall and why? What to extend to satisfy
    this other FS?

    IMHO as far as we have a syscall which satisfies almost all FS'es the
    other API's spread around the systems could be emulated in glibc (as with
    fork and clone).

    happy hacking,

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:54    [W:0.020 / U:24.484 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site