Messages in this thread | | | Subject | Re: [PATCH] PAG support, try #2 | Date | Wed, 14 May 2003 18:37:00 +0100 | From | 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 - 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/
| |