From: David Howells <dhowells@redhat.com>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: David Howells <dhowells@redhat.com>,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
openafs-devel@openafs.org
Subject: Alternative to PAGs
Date: Thu, 15 May 2003 15:15:49 +0100 [thread overview]
Message-ID: <6624.1053008149@warthog.warthog> (raw)
Hi Linus,
Okay, starting with a clean slate and writing PAGs off as a bad idea, how
about trying to work out what is required first? As I see it:
THE REQUIREMENTS
================
(1) Credentials/tokens/keys/whatever are held in a "keyring".
(2) A keyring is destroyed when the last reference goes away (kernel
resources are precious, though it may be possible to store credentials
in swapspace somehow).
(3) Every user has to have a default keyring that is created the first time
they log in [Linus demands this].
(4) A user has to be able to override the default keyring, such that they
can, for instance, perform operations on a remote filesystem with a
different credential.
(5) A user has to be able to run a program with a reduced set of
credentials.
(6) A process must be able to pass a subset of its credentials to a second,
already running process so that the second process can perform some
service on its behalf.
This gets tricky if the service process is performing services for a
number of processes simultaneously, each of which has its own set of
credentials.
(7) A process should be able to discard any credential it has access to,
particularly in conjunction with (6).
(8) It must be possible to withdraw a credential.
(9) The credentials governing access to a file must be associated with a
struct file, not with the process context currently accessing a file.
(10) A struct file will gain its credentials at the time it is opened.
POSSIBLE EXTENSIONS
===================
(11) Threads should perhaps share a common set of credentials, but be able to
adjust them on a per-thread basis (see (6)).
(12) A SUID process should add the credentials it gains from its new user ID
to those it inherited from its original context.
(13) There's one place Win32 has an advantage, I think: calls for setting up
handles (files, mutexes, etc) take security context parameters.
I think "groups" specific keyrings and arbitrary joinable keyrings are
superfluous (that's what ACLs are for) and a systems maintenance nightmare, so
I haven't included them.
SUGGESTED IMPLEMENTATION
========================
As far as implementation goes, perhaps each task_struct and each file should
point to a stack of keyrings:
+------+
| |
+--------------------->| USER |
| | |
| +------+
|
+------+ +------+ +------+ +------+
| | | | | | | |
| TASK |----->| SUID |---->| PRIV |---->| USER |
| | | | | | | |
+------+ +------+ +------+ +------+
^ ^
+------+ | |
| | | |
| FILE |---------+ |
| | |
+------+ |
|
+------+ |
| | |
| FILE |----------------------+
| | ^
+------+ |
|
+------+ +------+ +------+
| | | | | |
| TASK |----->| FILE |----------------->| USER |
| | | | | |
+------+ +------+ +------+
The keyrings in the stack would then be refcounted, and the next pointers
would be immutable.
struct keyring {
struct keyring *next;
struct keyring *conjunction;
struct list_head keys;
atomic_t usage;
int type;
#define KEYRING_USER 0
#define KEYRING_PRIVATE 1
#define KEYRING_SUID 2
#define KEYRING_FD 3
};
struct key {
struct list_head link;
atomic_t usage;
int type;
#define KEY_POSITIVE 0
#define KEY_NEGATIVE 1
void *credential;
};
And then add the following syscalls:
(*) auth_clear_stack(int completely)
Totally clear a process's stack (either completely or of everything but
the user credentials).
(*) auth_add_cred(const char *fs, const char *domain, void *data);
Add a new credential to the TOS keyring. The key would be negative if
data is NULL.
(*) auth_push_empty()
Push an empty keyring onto this process's stack.
(*) auth_push_fdcreds(int fd)
Push the credentials associated with fd onto the stack as a preferred
alternative.
(*) auth_pop()
Pop the top credential off of the stack.
David
next reply other threads:[~2003-05-15 14:03 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-05-15 14:15 David Howells [this message]
2003-05-15 16:53 ` Alternative to PAGs Linus Torvalds
2003-05-15 23:14 ` [OpenAFS-devel] " Garance A Drosihn
2003-05-16 0:46 ` Russ Allbery
2003-05-16 0:43 ` Garance A Drosihn
2003-05-16 0:56 ` Nathan Neulinger
2003-05-16 11:08 ` 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=6624.1053008149@warthog.warthog \
--to=dhowells@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=openafs-devel@openafs.org \
--cc=torvalds@transmeta.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox