From: David Howells <dhowells@redhat.com>
To: Trond Myklebust <trond.myklebust@fys.uio.no>, arjanv@redhat.com
Cc: dhowells@redhat.com, viro@parcelfarce.linux.theplanet.co.uk,
drepper@redhat.com, linux-kernel@vger.kernel.org,
linux-fsdevel@vger.kernel.org
Subject: [RFC] New authentication management syscalls
Date: Fri, 09 May 2003 14:11:17 +0100 [thread overview]
Message-ID: <11183.1052485877@warthog.warthog> (raw)
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
next reply other threads:[~2003-05-09 12:58 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-05-09 13:11 David Howells [this message]
2003-05-09 13:31 ` [RFC] New authentication management syscalls Christoph Hellwig
2003-05-09 15:39 ` Bryan Henderson
2003-05-09 17:44 ` David Howells
2003-05-09 18:39 ` Chris Wright
2003-05-09 20:06 ` David Howells
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=11183.1052485877@warthog.warthog \
--to=dhowells@redhat.com \
--cc=arjanv@redhat.com \
--cc=drepper@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=trond.myklebust@fys.uio.no \
--cc=viro@parcelfarce.linux.theplanet.co.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.