Messages in this thread |  | | | Date | Fri, 24 Sep 1999 11:28:24 +0200 (MEST) | | From | Konrad Rosenbaum <> | | Subject | Re: 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 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/
|  |