> Konrad Rosenbaum wrote:
>
> > > > 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.
> >
>
> If I am understanding correctly the problem is not the permission mode bits.
> I think it would be reasonably easy to come up with a common set of those.
> The problem is making a common interface for determining which user/entity
> those bits need to be set for. For example, how is it gonna know that
> 00008997-e0f0-21d0-8100-08005a4728f0, AFS ID 35223, and uid=500(haumont) are
> all actually user 'haumont'. It gets even worse with groups, for example
> haumont/admin, haumont:admin, and wheel should be the same group on my
> machine.
How do actual filesystems handle that? I guess they do nothing like that.
My quick'n'dirty idea would be this one: let userspace do the lookup and
let kernel store a small table of recently used U/GID's. The architecture
could look like that:
userspace: xfs_daemon knows where to find tables to match xFS ID's against
Linux ID's (or which server to ask and how to ask), it just polls on a
kind of kernel-daemon-connection and waits for questions to answer on.
[(Cache) Table of matches]<----[poll]
^
|
kernel: [small cache]---------->[call (in generic VFS level)]
/\ ^------,
[acl code] [other fs-stuff]
The VFS just calls the special FS (as usually done) which then tries to
find all necessary info in its cache and calls the attached userspace
daemon (by leaving a semi-permanent system call) and expects the
required info in the next call of that system call
this system call could lead into VFS so that we only need one daemon to
do this work (which could be started on bootup)
The syscall (as an example):
int sys_idmatch(struct s_fsmatch*);
struct s_fsmatch{
int fsid;/*id of the filesystem we need to match*/
int state;/*user->kernel errormessages*/
void*foreign;/*bigenough buffer for foreign ID's*/
uid_t native;/*native (Linux) representation*/
}
return value: the kind of request - examples:
FSM_UID request a UID match
FSM_GID request a GID match
FSM_BUF request to resize the buffer (native contains
size)
FSM_REGIST register a newly mounted fs (foreign contains all
info needed to find the match-table)
etc.
the trick here is that the daemon delivers the answer on a request in the
same struct as it gets the next request (perhaps some minutes or hours
later) when the syscall returns.
ok, I've only struggled around with commenting in/out DEBUG-macros, yet.
So i don't know how difficult this kind of syscall/daemon pair would be to
implement and debug, but I think it is a) easier and more flexible than
fully kernel-side solutions and b) much better than doing nothing.
> Still, even a bad interface (char *, tell the filesystem you figure it out?)
> would be better than nothing ...
agreed, but we should invest at least some hours in the design - nothing
becomes more permanent than temporary solutions :-(
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/