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: Re: [PATCH] PAG support, try #2 
In-Reply-To: <Pine.LNX.4.44.0305140924040.3107-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: Wed, 14 May 2003 18:37:00 +0100
Message-ID: <19800.1052933820@warthog.warthog>
From: David Howells <dhowells@warthog.cambridge.redhat.com>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 3048
Lines: 71


Hmmm... you aren't really taking about PAGs anymore, but no matter...

>    End result: again, this looks like it is designed for the _wrong_ usage 
>    of sharing a whole PAG or sharing nothing at all. Which is probably 
>    what current AFS users do, but it sounds inflexible and _wrong_ to me. 
>    The main PAG usage I personally envision would be something where the
>    PAG contains the decryption key to a filesystem or similar, which 
>    definitely is something where you (a) want to have multiple keys and
>    (b)  you want to have multiple PAG's that can share some keys without
>    being the same PAG.

It looks like what you want is for there to be a user_struct and a
group_struct, each with a list of tokens.

A process would then have the set conjuction of the sets of tokens
corresponding to its EUID, EGID and GROUPS.

> I suspect both of these problems could be fixed by another level of
> indirection: a "user credential" is really a "list of PAG's", with the PAG
> being a "list of keys". Joining a PAG _adds_ that PAG to the user 
> credentials, instead of replacing the old credentials with the new one.

And you'd need to be able to do a "subset" operation too (ultimately producing
an empty set), if only to run another program with reduced authority.

>  - users can controlledly join other PAGs as they wish (ie if you want to 
>    have credentials that are on top of the automatic user credentials, you
>    have to join them explicitly, which migth require a stronger password
>    or something)
> 
>    This allows for the "extra" credentials, and it also allows for users 
>    joining each others PAG's at least temporarily.

That makes the situation more complicated, because you wouldn't necessarily
want all processes owned by a user to gain (even temporarily) a token loaned
from one process to another.

>    It also allows things like extra groups outside of the traditional scope
>    of groups (ie you can set up ad-hoc groups by creating a new PAG, and
>    letting others join it).

And then you have to have some method of prioritisation. You may find that
user dhowells has a token for (fs=AFS,cell=redhat.com) and group engineering
has a token for (fs=AFS,cell=redhat.com). Which do you use?

> Anyway, I htink the current patch is totally unusable for any reasonable 
> MIS setup

What's "MIS"?

> (ie you couldn't make it useful as a PAM addition even if you tried),

OpenAFS does make it a useful and automatic PAM addition.

> and is totally special-cased for one (not very interesting, to me) use.

It can be used for other filesystems.

> And I think this will be a 2.7.x issue, if only because you guys will need 
> to convince me that I'm wrong.

Fair enough. I'm unlikely to get security added to my AFS client before the
2.6 freeze.

David
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/