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

[Andrew Deason]

On Tue, 12 Feb 2013 20:55:07 +0000
Chaskiel Grundman <cg2v@andrew.cmu.edu> wrote:

> Interpreting this as actual machines makes the most sense here. 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)

I think I was assuming that we could call GSSNegotiate for the specific
server we were talking to... but I realized you can only do that for the
per-cell key; we don't have different defined gss identities for the
individual fileservers (instead we get them from AFSCombineTokens, of
course). So yeah, I think this should be clarified the opposite way of
what I said, then :) I think the rest of that email still applies to
machines running the vlserver, though.

Anyway, my concern/confusion with this is that the per-server keys are
associated with a server UUID, which I believe is purely a notion of the
fileserver process. A bosserver has no notion of a UUID, and in fact a
server will not have a UUID of any kind if the fileserver process has
not been brought up yet. The practical problems for
per-server-keyed-servers, are then:

 1. If I want to talk to bosserver X, what UUID do I use for the
 AFSCombineTokens call?

 2. If I want to talk to bosserver X before its fileserver is up, how do
 I do so?

The answer to 1 I guess is that we VL_GetAddrsU the IP address we're
contacting. For that to work, we must guarantee that the IP we're
contacting is one of the ones that the fileserver for that box
advertises in the VLDB. That is currently not a requirement and seems
like something that could break in existing setups, but I guess that's
not terrible.

The answer to 2 obviously is that you can't, since the fileserver hasn't
registered its UUID (or key, for key auto-reg) in the vldb. However, it
seems like this should still be able to work for per-cell keys. Should
we maybe say that any server that accepts the per-cell key should accept
GSSNegotiate calls on the BOZO_ service? That way, you can still control
a machine with a per-cell key when the vldb is unavailable (even the
bosserver for a non-dbserver machine); the machines with a per-server
key still have the above restrictions.

-- 
Andrew Deason
adeason@sinenomine.net