Re: [OpenAFS-devel] Re: [PATCH] PAG support, try #2

[David Howells <dhowells@warthog.cambridge.redhat.com>]

> > Pardon me if I'm wrong, but doesn't the PAG already allow for multiple
> > credentials?
> 
> Yes, but the patch did not allow for
> 
>  -  partial sharing (keys are bound to _one_ PAG, and one PAG only)
> 
>     This makes "revoke" pretty much useless, since you have a damn hard 
>     time finding all the keys, since you have to copy them around instead 
>     of sharing one instance.

Okay, so separate PAG IDs and credentials. Have a separate credential cache
to which the PAG ID is but one of the keys, then share entries that have a
common (remote-user-ID,fsname,domain) key.

>     It also makes grouping very hard. 

Grouping is superfluous and not trivial at any time. Use ACLs.

>  - the name space is so limited that you _have_ to consider the PAG ID's 
>    temporary, which means that you have to add a whole new layer of 
>    maintenance in user space.

PAG IDs _are_ ephemeral.

> Neither of these are apparently problems in the AFS world, because there 
> is only one entity that gives out keys, so that one entity can keep track 
> of every key ever allocated.

That's not exactly so (see next comment).

> But look at the big picture. What happens when you have multiple sources 
> of keys that have nothing to do with each other.

Like AFS, you mean? Each AFS cell (or cell group) may contain an independent
kerberos server that dispenses keys that are nothing to do with the kerberos
tickets granted by another cell.

For instance, the openafs.org cell my grant me a ticket for accessing there,
but that wouldn't be any use for redhat.com or cambridge.redhat.com
cells. Whereas the redhat kerberos server might grant me a ticket that'd
permit me to access either redhat cell.

> How do you maintain sanity in that kind of world, when the numbers don't
> have any meaning, and one of the key maintainers doing a "join" operation
> will throw away all the work that the other key maintainers did.

Assuming there is a join operation. I think setpag() should go, leaving only
newpag().

> >	  Linus seems to be arguing for multiple PAGs, like multiple
> > GIDs. But I think that functionality is really there, inside the PAG.
> 
> No it isn't. You can't do independent joins, since as it is, the code has
> an "all or nothing" approach.

Independent joins aren't necessarily good either. They add lots of complexity
and consume lots of kernel resources.

> Again, this works in a single-use environment, where there is central 
> control. It _sucks_ if you want to have a generic "bunch of keys" model.

I've tried to make my PAG patch support a multi-use environment.

David