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

[Andrew Deason]

On Wed, 13 Feb 2013 00:32:54 -0500 (EST)
Benjamin Kaduk <kaduk@MIT.EDU> wrote:

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

I don't think so; if you only use RegisterAddrs but use the per-server
key thing, it's still tied to the UUID. You need to specify the UUID to
AFSCombineTokens in order to get tokens for that server.

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

As you mention later, a BOZO_GetUUID may not be a good idea. I think it
doesn't make a lot of sense to expose the fileserver UUID through that.
While it's conceivable to generate some new bozo-specific UUID to
identify the server, I don't think that's worthwhile.

I assume above you are talking about the case where bosserver remote
access stops working because someone changed the hostname. While I do
think that's annoying, it doesn't need to be as potentially disastrous
as I originally mentioned. It's possible to have the implementation
somewhat check for that at startup, making the error obvious early on.
Using a separate bos identity for each server seems fine.

And as has been mentioned, this stuff doesn't need to go in this
document, since it's not for contacting RXAFS, VL, et al. But I could
see a small note about how other AFS services are not specified here,
but they could just use bare gssnegotiate credentials, using their own
per-server identity or the cell-wide key.

-- 
Andrew Deason
adeason@sinenomine.net