New authentication management syscalls

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

fs is the path to a mount point?

s/filesystem/mount instance/

This should go into super_operations instead.

*data)

A filesystem is the contents of a disk (or equivalent). It looks to me like the data gets presented instead to a filesystem driver. And since filesystem drivers aren't really known by names, I'd say 'fs' is the name of the filesystem type (e.g. "ext2") which the filesystem driver implements.

I base some of this presumption on the fact that settok() is implemented by a routine registered in struct file_system_type, not struct super_block.

Hi Christoph,

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

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

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