Re: [PATCH] PAG support, try #2

[David Howells]

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