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

[Benjamin Kaduk]

On Wed, 13 Feb 2013, Andrew Deason wrote:

> On Wed, 13 Feb 2013 11:54:15 -0500 (EST)
> Benjamin Kaduk <kaduk@MIT.EDU> wrote:
>
> It's still used by some sites I know about. But, for upserver and any
> other server components you're talking about, I really think you can
> just either not implement rxgk for them for now, or at least just assume
> you can use the cell-wide key. If some per-host keying is desired, it

Yeah, update and backup are late on the list of services to be converted 
to rxgk.  Actually, I'm probably going to go for getting things working 
with the cell-wide key before splitting out to the per-server key stuff.

> I believe it is a server; isn't it what handles the TC_* RPCs? It's been
> a long time since I ran a buserver-based backup thing, but I thought the
> "port offsets" you specify point you to a specific machine and port,
> which is where a butc process is running. I thought the only reason it's
> not run from e.g. bosserver is that it needs to be in the foreground,
> since for some configurations an operator needs to be there to hit
> 'enter' when changing a tape or something.

Yup, my reading is that butc is a server that just happens to need a 
controlling terminal.

> If what I'm remembering is at all correct, you could have per-server
> keys for the server portion, but it would have to be it's own system,
> not tied to the fileserver stuff. You'd either have an identity for a
> particular port offset maybe (similar in function to fileserver uuids),
> or just use something based on the hostname. But I really don't think we
> need to worry about that yet.

Most likely not.  An outline of a plan is the most I want at this point.

>> I guess I would have expected a fileserver to call
>> VL_RegisterAddrsAndKey when it (re)starts, which produces a new key.
>> I suppose this does not technically have to invalidate existing
>> tokens, my expectation was that it would do so.  There's also the
>> matter that this RPC must be called over an RXGK_LEVEL_CRYPT
>> connection, so the fileserver must have a GSS identity to produce a
>> token for that connection.  This could just be the machine's host
>> keytab, I think, and does not need to be connected to anything that
>> might be used by an RX service as an acceptor.
>
> Am I maybe missing something, or is the document lacking any guidance
> for the identity used for the VL_RegisterAddrs* calls? If you used the
> host keytab, I assume you'd then restrict the VL_RegisterAddrs* calls to
> anything that looks like host@*, but then you allow any host with a host
> keytab to register. I'd think maybe you'd want a different instance for
> this, since you'd only hand them out to machines you'd allow to register
> as fileservers (maybe afs3-fileserver@<host>).
>
> I recognize that is an operational question and not really a protocol
> spec, but it seems like the place for offering guidance to implementors
> and operators.

It seems a fair question to ask.  I was assuming it was not a particularly 
important question because actually putting content on the departmental 
server would require action by the cell-wide admins for creating volumes 
and such.  But if that's the case, it's unclear what benefit there is to 
running a departmental fileserver, if all you can do is start and stop the 
fileserver.  So I think your afs3-fileserver@host idea is probably a good 
one, and such principals should be allowed to add/remove volumes on the 
fileserver that they register as.  But those bits shouldn't require 
protocol specification, just ACL implementation on the dbserver side.


-Ben