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

[Simon Wilkinson]

>> 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>).
>=20
> 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.

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

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.

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

Cheers,

Simon.=