[RFC] New authentication management syscalls

[RFC] New authentication management syscalls

[David Howells]

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

Re: [RFC] New authentication management syscalls

[Christoph Hellwig]

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.

Re: [RFC] New authentication management syscalls

[David Howells]

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

Re: [RFC] New authentication management syscalls

[Chris Wright]

* 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

Re: [RFC] New authentication management syscalls

[David Howells]

> > 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