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