On Thu, 14 Feb 2013 08:49:12 +0000 Simon Wilkinson <[email protected]> wrote:
> 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. afs3-fileserver@<UUID>.<cell> ? Needing to export the identity based on the UUID seems pretty annoying, though (I think most operators aren't really familiar with the idea of a fileserver even having a uuid). However, I don't think the first 'leap of faith' / race is too bad. The only security issue I see is if you issue several of them at around the same time; then any of those in that batch could screw up the others in that batch (and you'd notice pretty quickly, I think). If you just issue one at a time and wait for it to register, that fileserver can only mess with its own UUID, or presumably any UUID for an rxkad-only fileserver. The latter could possibly be prevented by requiring an administrator to flag something in the vldb that indicates a given UUID is about to be upgraded from rxkad to a departmental rxgk fileserver. But I think the common case for per-server keys would be completely new fileservers, or migrating from a cell-wide key, so maybe you could just not allow that at all. I mean, if you're upgrading from rxkad, they just had the cell-wide key, so temporarily given them a cell-wide key to upgrade doesn't seem terrible. -- Andrew Deason [email protected] _______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
