[OpenAFS-devel] Re: Alternative to PAGs

[David Howells]

------- Blind-Carbon-Copy

To: Linus Torvalds <torvalds@transmeta.com>
cc: David Howells <dhowells@redhat.com>, linux-kernel@vger.kernel.org,
    linux-fsdevel@vger.kernel.org
Subject: Re: Alternative to PAGs
In-Reply-To: <Pine.LNX.4.44.0305150920400.1841-100000@home.transmeta.com>
User-Agent: EMH/1.14.1 SEMI/1.14.4 (Hosorogi) FLIM/1.14.4
 (=?ISO-8859-4?Q?Kashiharajing=FE-mae?=) APEL/10.4 Emacs/21.2
 (i386-redhat-linux-gnu) MULE/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi")
Content-Type: text/plain; charset=US-ASCII
Date: Fri, 16 May 2003 12:08:25 +0100
Message-ID: <12699.1053083305@warthog.warthog>
From: David Howells <dhowells@warthog.warthog>


> >   (1) Credentials/tokens/keys/whatever are held in a "keyring".
>
> Not "a keyring". At least to me, a "keyring" implies a "bunch of keys",
> with no structure to it. That's not what you want from a maintenance
> perspective.

I don't think I was clear. I meant "keyring" as a container holding a bunch of
keys, not as in an auth session (ie "a bunch of keyrings, ordered in some
fashion").

What do you mean by "structure" anyway? You later seem to assume a
session/keyring is just an arbitrary key container holding a set of
potentially unrelated keys.

> You want to have multiple keyrings, with the ability to say "I am now done
> with those keys I got from source X". That doesn't mean that you drop all
> your credentials, it only means that you have stopped one "session" (and
> clearly a session should be able to have many keys).

I never suggested that it would mean that.

I take it you mean "session" == "keyring" in this terminology?

> Also, the fact that you have a default one MUST NOT preclude you from
> having access to _another_ keyring too.

Agreed. But you still need some way to say in any given situation the order in
which keyrings should be considered, and whether or not they should be
considered.

> But accessing that other keyring does not mean that the keys from that
> should be added to your default keyring: you're sharing the default keyring
> with other processes, so modifying your default one to add capabilities to
> _one_ process is clearly the wrong thing to do.

Okay, I can accept that.

> In other words, you want to not maintain individual keys, you always want
> to maintain a _group_ of keys. You don't get "a key" by default. You get
> "a group of keys" by default. The group may, of course, contain just a
> single key.

Are you thinking that all the keys in a keyring should come from the same
authority (for instance Redhat's Kerberos service)? If so, that might make
"labelling" them easier... On the other hand, that would then mean you'd need
sessions to be groups of rings, so maybe not.

> So what I think you want is a hierarchy:
>
>  - "my credentials" is a "set of keyrings"
>  - a "keyring" is a "set of keys" aka a "session" (when used as a AFS
>    session, this is a PAG. Other users might have other naming conventions
>    for their sets of keys)
>  - a "key" is an indivisible blob, as far as the base kernel is concerned
>    (and likely most users of the key too, for that matter).

This precludes anything but AFS using PAGs... All a PAG is is a unique (though
recyclable) label by which a credentials can be indexed.

> A key must be on a ring, ie all keys are part of a "session".

I take it you mean a key must be on at least one ring...

> But a session may be associated with an arbitrary number of processes, and a
> process must be able to maintain multiple sessions at once.

I think, then, there must be facilities for:

 (1) listing (or iterating over) the keyrings/sessions to which a process
     subscribes.

 (2) listing the keys inside a keyring to which a process subscribes.

 (3) creating a new keyring.

 (4) linking a key from any keyring to another (like the link() function does
     for files).

 (5) adding a new key to a keyring.

 (6) updating a key in a keyring (ie: avoiding expiration).

 (7) withdrawing a key from a keyring.

 (8) unsubscribing from a keyring.

 (9) opening a file with reference to a particular keyring.

(10) rearrange the set of keyrings (read sequence rather than set, I suppose)
     to affect the search ordering.

> >   (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.
> 
> I disagree. Your (4) comes from your (1) - inability to have multiple 
> keyrings. If you have multiple keyrings, you don't "override" anything. 
> You just have a stackign order (ie the credentials is a _sorted_ list of 
> keyrings), and you search the credentials for valid keys in order.

Yes, that is one way of overriding the default keyring.

> >   (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.
> 
> A "subset of credentials" _is_ a keyring. You only ever pass keyrings 
> around. You don't pass individual keys around, but you also aren't forced 
> to pass off _all_ of your credentials at the same time. 

Okay.

> I think you have a few (different) cases of invalidation:
> 
>  - you "change the lock" (ie the old key that gave you something now 
>    becomes useless)
> 
>  - you remove access to a group of keys (ie you remove a keyring, aka 
>    "terminate a session" for one user). Other processes in that session
>    still have access to the keyring.
> 
>  - you maintain a session/keyring (add or remove keys from it, and all
>    processes usign that session will see the changes to the session).
> 
> So there are at least three (very different) set of operations that 
> withdraw a credential and work on different levels. 

I can think of a fourth: updating a key that was due to expire, though that
would best be done as a combo delete & add operation as keys ought to be
immutable once created.

> >   (9) The credentials governing access to a file must be associated with a
> >       struct file, not with the process context currently accessing a file.
> 
> This does beg the question: which level of credentials does the file get
> associated with. Does it get _all_ the credentials that the opener had (ie
> access to every keyring)? Or does it get associated with the one session
> that the open() decided was relevant? Or does it get associated with the
> single key that was used for the open?
> 
> I suspect that the open file should be associated with one "session". 

I agree. If you can construct a new keyring with an arbitrary subset of all
the keys you have access to, then you can say "open with _that_ keyring"
(though the keyring in question might be the default FS op one, sort of like
fsuid).

> >  (12) A SUID process should add the credentials it gains from its new user
> >       ID to those it inherited from its original context.
> 
> But it has to keep them _separate_: it needs to be able to drop it's own 
> extra keys at some point, and revert to "non-suid-ness".

Okay, I'll grant you that. I have seen a document discussing PAGs (for Coda I
think it was) that suggested that SUID program execution places the process in
a new PAG, and that setuid(SAVED_IDS) reverts to the original.

> This is why it's so important to consider the "set of credentials" to be
> more than just a "bunch of keys". It has to be bunched up some way.

See my suggestion above

> And my suggestion is that the keyring is that "bunch", and that a suid 
> application is nothign more than one that got a special keyring at 
> execve() time. A keyring that it can choose to drop.

Fair enough. Should UID/GID/GROUPS[] then be a credential/key in its own
right? If that's the case, then a process should be able to select a key (or
keyring) as being the one to supply this information.

David

------- End of Blind-Carbon-Copy