> On Tue, May 13, 2003 at 06:42:49PM +0100, David Howells wrote:
> > I have a further suggestion for some new system calls specifically for
> > managing tokens. I'd like to add the following:
> >
> > (1) settok(const char *fs, const char *key, size_t size, const void *data)
> >
> > Present data to the named filesystem as being the authentication
> > token for the specified key (eg: an AFS cell). If accepted, this
> > token should be stored in the PAG to which the calling process
> > belongs.
>
> Tokens are very filesystem specific, with Coda the kernel really doesn't
> know in which 'realm' any object is located. So it will always just pass
> the PAG to the cache manager which will associate the right token to
> access the file.
OTOH, since settok wouldn't modify the PAG ring directly, but would rather
jump through a vector in the file_system_type object, it could deside to
confer with userspace and possibly not add a token at all.
Of course then the other calls would also have to vector through the
file_system_type object rather than affecting the PAG directly, but I'm happy
to do that.
> A minimal kernel implementation really only has a single newpag()
> systemcall and internal 'getpag()' that can be used by filesystems. All
> the token handling can be done by a (possibly filesystem specific)
> userspace daemon that is given a (pag,realm/key) tuple and returns a
> token.
>
> But ofcourse Coda is a 99% userspace implementation, so I'm already
> assuming that there are one or more userspace daemons.
This would just be a "standardised" way of communicating authentication info
to a filesystem. What the filesystem then did with it would be up to that
filesystem. Storing a token in a PAG or attached to a struct file would then
just be one option.
> > (2) gettok(const char *fs, const char *key, size_t size, void *buffer)
> >
> > Get a copy of an authentication token.
>
> Not sure what the use of this is for userspace. I can see how your
> kernel module would use it.
OpenAFS has it, but I'm not sure what uses it.
> btw. is the 'size_t size' the size of the key, or the size of the buffer?
Actually the buffer size. I was assuming the key would be a NUL terminated
string, but it's probably best not to assume that, and I should add an extra
argument for the key size.
Filesystem name can remain a NUL terminated string as I'd have to search the
file_system_type structures.
> > (4) cleartoks(const char *fs)
>
> Isn't this simply deltok(fs, NULL)?
Probably.
David
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu May 15 2003 - 22:00:47 EST