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

[Benjamin Kaduk]

On Thu, 14 Feb 2013, Simon Wilkinson wrote:

>
>>> 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>).
>>
>> 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.
>
> The benefit of a departmental fileserver is that it allows you to let 
> people run fileservers that you don't trust with your cell-wide key. 
> It's about much more than just starting and stopping the fileserver.

Oh, certainly.  I was just following some steps of reasoning that got me 
to a place where starting and stopping was all that was possible, which 
led me to say, "this is wrong".  Now we are figuring out where that chain 
of reasoning went wrong.

>>  So I think your afs3-fileserver@host idea is probably a good one,
>
> The issue here is similar to the issue with SetCallbackKey. The 
> fileserver's identity is a UUID (it explicitly cannot be a hostname, as 
> one of the things that RegisterAddrs allows is for a fileserver to 
> migrate between IP addresses). So, you're asserting that a particular 
> identity can move (and rekey) a fileserver. Restricting this to 
> identities of the form afs3-fileserver@host protects you against general 
> abuse, but would still allow one departmental fileserver admin to wreak 
> havoc with another fileserver.

Sure.

> The possibilities here seem to be requiring the identity<->UUID mapping 
> to be part of the server configuration (which would permit any form of 
> identity to be used), using a leap of faith where the first identity 
> used to register a UUID is the only one which can then make changes to 
> that UUID, or using an identity which contains the server's UUID. For 
> the latter, using afs3-fileserver@UUID is tempting, but means that we 
> lose any domain-to-realm magic that may be required.

I'll read the rest of the thread, but leap of faith doesn't sound that bad 
-- exposing the UUID at this level seems awkward.

>> and such principals should be allowed to add/remove volumes on the 
>> fileserver that they register as.
>
> Volumes are added and removed from the vldb by 'vos' using the identity 
> of the user invoking that command, not by the volserver. So you need to 
> have ACLs for the user calling vos, rather than any identity you assign 
> to the fileserver.

Yes.  At some point I had gotten an idea in my head to run these vos 
commands on the (departmental) fileserver with -localauth, so that the 
identity used to invoke the RPCs is the fileserver's identity; the vldb 
could then always grant permission for volume operations on the fileserver 
which are authenticated as "the fileserver's identity".  As the rest of 
this thread is making clear, that idea of mine is not fully baked, and I 
don't think I clearly explained it before, anyway.

-Ben