[AFS3-std] Re: rxgk-afs tokens for ptservers, etc.

[Jeffrey Hutzelman]

On Tue, 2013-02-12 at 20:55 +0000, Chaskiel Grundman wrote:
> >  [Last paragraph of section 3]
> >  Tokens returned from the GSSNegotiate call MUST only be used with
> >   database servers.  Tokens for fileservers MUST be obtained by calling
> >   AFSCombineTokens before each server is contacted.
> >
> > Without context, that doesn't seem clear to me whether it means the
> database server processes and the fileserver process, or if it means the >
> actual machines. 
> 
> Interpreting this as actual machines makes the most sense here.

Operationally, maybe, but in terms of code structure and the way server
implementations work, I think not.

The idea here is that if you obtain an rxgk token from, say, a vlserver,
you can use it to talk to that vlserver.  You can also use it to talk to
other vlservers and to the other database services, because those
services pretty much have to be centrally managed and already have to
share keys, so having them able to interpret each others' tokens is not
a hardship.  Doing it that way makes life a lot easier given the
existing AFS client architecture, because it allows all the GSS bits to
stay in aklog or whatever, and doesn't require preemptively getting
tokens for every dbserver in order to make sure you'll have one for
whichever server happens to still be up when you want to do an
operation.

Fileservers, on the other hand, are a different beast.  The idea is that
whenever you talk to a specific fileserver, you get a token for that
server.  But, you get it via AFSCombineTokens, rather than from scratch,
because that means the CM doesn't have to have the client's original
credentials around or else know up front what all the possible
fileservers are.

For consistency in both CM and server implementations, it's better if
this model applies even to fileservers which happen to be on the same
machine as a database service.  In fact, it's better to avoid thinking
too hard about "machines".  A fileserver is reachable at the address(es)
(and, eventually, ports) the vlserver advertises.  Those might be the
same as some address by which the vlserver itself is reachable, but I
see no reason to conflate those (certainly, on the implementation side,
processes co-located on the same machine might end up using the same
key).

Further, requiring combined tokens for all fileserver accesses means
that the vlserver has the opportunity to inject additional authorization
information or whatever into the tokens it creates.  We might not have a
use for that today, but if we ever did, it would be nice to be able to
depend on clients always doing it.



Finally, I think the rule as it applies to fileservers also needs to
apply to volservers.  Among other things...

>  One of the
> purposes for all this complexity is so that fileserver machines (running
> bosserver, fileserver and volserver processes) can have unique keys not
> shared with all the other server hosts in the cell. This is somewhat simpler
> administratively, but also enables a cell to have servers administered by
> multiple groups that don't trust each other (everyone must trust the
> database server maintainers, but that's it)


And if that's the case, then you need a server-specific token to talk to
a volserver.


I'm not sure what to do about the bosserver.  It's really more of a
management tool than part of the main protocol suite.  It seems like, at
a minimum, it ought to be possible to obtain a token for a given
bosserver by negotiating directly with that server, the same as for any
other rxgk service.  Arguably the same should be possible for volservers
and maybe even fileservers, though in practice that doesn't seem as
useful.

-- Jeff