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

[Benjamin Kaduk]

On Tue, 12 Feb 2013, Andrew Deason wrote:

> On Tue, 12 Feb 2013 20:55:07 +0000
> Chaskiel Grundman <cg2v@andrew.cmu.edu> wrote:
>
> 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

Well, we allow out-of-band key management as well as 
VL_RegisterAddrsAndKey to get per-server keys.  So conceivably, those 
could have GSS identities.

> 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

Again, only if the RegisterAddrsAndKey method is used.  But we want to 
support it, so we must have a way to cope regardless.

> 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.

My original thought when I was pondering this problem was to have the 
bosserver provide RXGK_GSSNegotiate as well as the vlserver, with the 
expectation that a bos token was only usable with bos.  But, as you note, 
machines with only a fileserver will still run a bosserver to manage the 
fileserver, and may not have a GSS identity avaialble.

I am somewhat inclined to only solve (2) and ignore (1) entirely, 
essentially destroying the tie between a bosserver and the fileserver on 
the same host.

It seems that, just as rxkad first tries afs/cellname@realm and then 
afs@realm, it is reasonable to try negotiating with the cell-wide key 
against a particular bosserver and then try a per-server identity. Per my 
other mail, if there has ever been a running fileserver on the host, there 
may be a per-server key on disk. It's not (necessarily) a GSS identity, so 
we can't negotiate for it directly, but the vldb would still hold that 
key.  However, the key is indexed in the "vldb" (the key is not 
necessarily in the db per se) by the fileserver uuid, as you note. (I'm 
not familiar enough with the innards of the vldb to say whether the 
per-server key would actually still be in the vldb at this point, which 
could sink my plan.  It also occurred to me that we should probably track 
a kvno for these per-server keys if we want to use the same TokenContainer 
for per-server tokens as for cell-wide tokens.) I think it might be 
cleaner to add a BOZO_GetUUID RPC to expose the uuid and then 
AFSCombineTokens against that uuid to get a bosserver token.

This still does not help when bosserver is started for the very first 
time, or if the per-server key or sysid file is missing or corrupted. 
That's a drawback, but the argument Andrew presented against a separate 
rxgk-bos GSS identity does seem valid, and this seems to be a way to avoid 
a separate rxgk-bos GSS identity.

I'll need to think more about how/whether things will work when setting up 
a new (departmental) fileserver, but it may work.  It also seems to reduce 
the complexity involved in getting a token to talk to a bosserver, which 
is probably a good thing.

-Ben