On Sat, 2 Mar 2013, Simon Wilkinson wrote:
On 2 Mar 2013, at 18:30, Benjamin Kaduk <[email protected]> wrote:
I'm in a similar position as jhutz; I think I understand what the callback
protection mechanism should look like, and it doesn't involve protocol level
changes outside of SetCallBackKey.
When a server receives a SetCallbackKey RPC, which set of callbacks does
that RPC apply to?
The flip answer is of course "those from the same client" [over
connections using the indicated security index].
Actually specifying what that means does require some effort; the current
text in the rxgk-afs document is attempting to say that RPCs made over an
rxgk-authenticated connection, where one of the identities in the token
used to authenticate the connection matches the identity used to secure
the SetCallBackKey RPC, will use the key set by the SetCallBackKey RPC.
This is okay for keyed cache managers, where the intent is that a CM
identity will be unique per host, and the SetCallBackKey RPC is called
using a token with just one identity, the CM-specific identity. If that
CM identity is shared between multiple hosts or a single-user CM is using
the user's identity to register SetCallBackKey, this falls apart quickly.
But, we have other ways to identify clients. In particular, we have a
UUID for the cache manager, and this UUID is sent as the appdata field of
the rxgk authenticator. Given that we are indexing fileservers by UUID
for AFSCombineTokens purposes, it seems reasonable to index clients by
cache manager UUID for callback purposes. The (UUID,
SetCallBackKey-securing identity) pair seems like it should be enough to
uniquely identify a client for callback purposes, at least on quick
inspection.
-Ben
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://lists.openafs.org/mailman/listinfo/afs3-standardization
