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

[Andrew Deason]

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

> > Possibly.  On the other hand, the upserver might just as usefully
> > use a host-based service.  It is a management tool that is not
> > particularly tied to the AFS service other than by being shipped in
> > the same source tree.  I sort of wonder how many people are even
> > still using it.
> 
> I also wonder.  It's certainly not in the critical path for my rxgk
> implementation roadmap, but I think it's still worth thinking about
> how it would work.

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
can be specified later. I don't think it has a lot of relevance to the
per-fileserver keys we're specifying, since none of those other services
can make use of the fileserver UUID.

> > No, butc is not a component that runs on fileservers.  It's the tape
> > controller, and runs in places that have tape drives, or whatever
> > passes for them.  Volume dumps are obtained from fileservers via the
> > volume dump mechanism.  To my recollection, butc is also actually
> > not really a server.  It gets run by an admin, with admin
> > credentials.
> 
> The documentation is pretty clear that butc is started manually by an
> administrator and runs with administrator tokens, but I'm not entirely
> sure what the privilege is used for.  If it's just fs/volser stuff,
> that could be done with not-the-cell-wide-key, but if the vldb is
> modified, maybe not.

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.

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.

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

-- 
Andrew Deason
adeason@sinenomine.net