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 type;/*ACL_USER/ACL_GROUP | ACL_GRANT/ACL_REVOKE*/
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,
Konrad
-
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/