lkml.org 
[lkml]   [1999]   [Sep]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
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 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/

\
 
 \ /
  Last update: 2005-03-22 13:54    [from the cache]
©2003-2011 Jasper Spaans