* [RFC] New authentication management syscalls
@ 2003-05-09 13:11 David Howells
2003-05-09 13:31 ` Christoph Hellwig
0 siblings, 1 reply; 5+ messages in thread
From: David Howells @ 2003-05-09 13:11 UTC (permalink / raw)
To: Trond Myklebust, arjanv
Cc: dhowells, viro, drepper, linux-kernel, linux-fsdevel
Hi Trond, Arjan,
I'm trying to come up with a way of allowing userspace to present
authentication tokens to the kernel. What I've come up with involves the
addition of six system calls:
(1) setpag()
Put the calling process into a new process authentication group (PAG).
(2) getpag()
Get the PAG ID of the calling process.
(3) 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.
(4) gettok(const char *fs, const char *key, size_t size, void *buffer)
Get a copy of an authentication token from the current PAG.
(5) deltok(const char *fs, const char *key)
Delete an authentication token from the current PAG.
(6) cleartoks(const char *fs)
Clear all the tokens belonging to a particular filesystem from the
current process's PAG.
The kernel would need to be modified in a number of ways:
(1) PAGs would need to be uniquely numbered managed kernel object. Each
process should belong to a PAG. Each PAG would contain a list of tokens.
(2) I'd like to include Trond's vfs_cred idea (move fsuid, fsgid and groups
out of the task_struct) and make the vfs_cred point to the PAG for the
process.
(3) The struct file_system_type would gain at least one new entry point:
struct file_system_type {
...
int settok(struct file_system_type *fstype,
const char *domain,
size_t size,
const void *data);
};
If this method returned 0, then the token would be added to the PAG's
list, if it returned an error, then it'd be ignored.
David
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [RFC] New authentication management syscalls
2003-05-09 13:11 [RFC] New authentication management syscalls David Howells
@ 2003-05-09 13:31 ` Christoph Hellwig
2003-05-09 17:44 ` David Howells
0 siblings, 1 reply; 5+ messages in thread
From: Christoph Hellwig @ 2003-05-09 13:31 UTC (permalink / raw)
To: David Howells
Cc: Trond Myklebust, arjanv, viro, drepper, linux-kernel, linux-fsdevel
On Fri, May 09, 2003 at 02:11:17PM +0100, David Howells wrote:
> (3) settok(const char *fs, const char *key, size_t size, const void *data)
fs is the path to a mount point?
> 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.
s/filesystem/mount instance/
>
> struct file_system_type {
> ...
> int settok(struct file_system_type *fstype,
> const char *domain,
> size_t size,
> const void *data);
> };
This should go into super_operations instead.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [RFC] New authentication management syscalls
2003-05-09 13:31 ` Christoph Hellwig
@ 2003-05-09 17:44 ` David Howells
2003-05-09 18:39 ` Chris Wright
0 siblings, 1 reply; 5+ messages in thread
From: David Howells @ 2003-05-09 17:44 UTC (permalink / raw)
To: Christoph Hellwig, David Howells, Trond Myklebust, arjanv, viro,
drepper, linux-kernel, linux-fsdevel
Hi Christoph,
> > (3) settok(const char *fs, const char *key, size_t size, const void *data)
>
> fs is the path to a mount point?
No. "fs" is the name of a filesystem.
I think this might be a better idea than the name of a mountpoint as it would
then be possible to set the tokens prior to mounting, maybe so that you _can_
mount.
I'm thinking a bit of samba here, where authentication information needs to be
passed upon mounting (workstation/domain, username, password).
David
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [RFC] New authentication management syscalls
2003-05-09 17:44 ` David Howells
@ 2003-05-09 18:39 ` Chris Wright
2003-05-09 20:06 ` David Howells
0 siblings, 1 reply; 5+ messages in thread
From: Chris Wright @ 2003-05-09 18:39 UTC (permalink / raw)
To: David Howells
Cc: Christoph Hellwig, David Howells, Trond Myklebust, arjanv, viro,
drepper, linux-kernel, linux-fsdevel
* David Howells (dhowells@warthog.cambridge.redhat.com) wrote:
>
> I think this might be a better idea than the name of a mountpoint as it would
> then be possible to set the tokens prior to mounting, maybe so that you _can_
> mount.
>
> I'm thinking a bit of samba here, where authentication information needs to be
> passed upon mounting (workstation/domain, username, password).
How does this map up with Viro's idea of a two stage mount. IIRC, it
was someting akin to:
fsfd = open(/dev/fs_type/ext2)
write(fd, "device and options, potentially including auth...");
mntfd = open("mntpt");
newmount(fd, mntfd, MNT_ATTACH);
or something like that. Wouldn't that give you a free form abiility to
talk to the fs driver and authenticate as needed? Is this plan still
alive?
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [RFC] New authentication management syscalls
2003-05-09 18:39 ` Chris Wright
@ 2003-05-09 20:06 ` David Howells
0 siblings, 0 replies; 5+ messages in thread
From: David Howells @ 2003-05-09 20:06 UTC (permalink / raw)
To: Chris Wright
Cc: David Howells, Christoph Hellwig, David Howells, Trond Myklebust,
arjanv, viro, drepper, linux-kernel, linux-fsdevel
> > I think this might be a better idea than the name of a mountpoint as it
> > would then be possible to set the tokens prior to mounting, maybe so that
> > you _can_ mount.
> >
> > I'm thinking a bit of samba here, where authentication information needs
> > to be passed upon mounting (workstation/domain, username, password).
>
> How does this map up with Viro's idea of a two stage mount. IIRC, it
> was someting akin to:
>
> fsfd = open(/dev/fs_type/ext2)
> write(fd, "device and options, potentially including auth...");
> mntfd = open("mntpt");
> newmount(fd, mntfd, MNT_ATTACH);
>
> or something like that. Wouldn't that give you a free form abiility to
> talk to the fs driver and authenticate as needed? Is this plan still
> alive?
Then you end up with a copy of the token for every mountpoint, which may not
be what you want.
With my AFS client for instance, you want at most one token per cell per
PAG. Each cell contains potentially lots of volumes, and each volume is
mounted as a separate mount.
OTOH, with OpenAFS, you get one mount for everything and everyone, and that
contains all cells and all volumes, and so will almost certainly have the
tokens uploaded post-mount.
David
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2003-05-09 19:54 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-05-09 13:11 [RFC] New authentication management syscalls David Howells
2003-05-09 13:31 ` Christoph Hellwig
2003-05-09 17:44 ` David Howells
2003-05-09 18:39 ` Chris Wright
2003-05-09 20:06 ` David Howells
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).