>> 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. > 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. 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._______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
