On Fri, 1 Feb 2013 15:54:42 -0500 (EST) Benjamin Kaduk <[email protected]> wrote:
> The rxgk-afs draft currently only mentions vlservers and fileservers, > with only a passing mention of database servers. If we want to stick > to defaulting to the vlserver for GSSNegotiate, we should probably > mention that other database servers are expected to be able to accept > such tokens. Alternately, we could specify that all database servers > must offer the negotiation service, but that doesn't seem quite right. > (The bosserver will need special treatment, though, as we want to be > able to use rxgk authentication to bring up the vlserver!) First of all, the current draft mentions the following, which I think may be a little unclear: [Last paragraph of section 3] Tokens returned from the GSSNegotiate call MUST only be used with database servers. Tokens for fileservers MUST be obtained by calling AFSCombineTokens before each server is contacted. Without context, that doesn't seem clear to me whether it means the database server processes and the fileserver process, or if it means the actual machines. It seems like it would make more sense to me to say to only use AFSCombineTokens when talking to fileserver processes via RXAFS_* calls, and all other processes can use tokens from GSSNegotiate. Does that make sense? I'm not sure if RXAFS_* calls is how you specifically want to make that distinction, but I think you know what I mean. AFSCombineTokens is only for traffic dealing with clients fetching/storing/etc data to/from fileservers, not for administrative actions. > Any thoughts one way or the other? Now, as you say, if we have GSSNegotiate only running via the vlserver, obviously that's a problem since we can't authenticate if the vlserver isn't up. Conceptually I think it would make sense to run that on the bosserver instead (since that's always around) except: 1. BOZO_ doesn't really seem like a client-friendly interface; so far it's only been for administrative tools. So I've been kind of considering it like the VOLSER_ RPCs, in that compatibility etc is a little less important, since it doesn't talk to random clients. 2. Existing firewalls and stuff surely let the vlserver port through, but may not let the bosserver port through. So, moving GSSNegotiate doesn't seem like the answer. But, to me it would make sense to say we run GSSNegotiate on vlservers and on bosservers. For acquiring credentials for administrative actions, try bosserver first; for user credentials intended for fileserver access, try vlserver first. Thinking down the road, I'm not sure how we're going to make that choice user-visible in the implementation, but it seems more tractable than needing to specify which 'service' to authenticate to when you acquire credentials. This requires bosserver to be running and reachable to have authenticated access to e.g. ptserver, but that seems reasonable (and certainly more reasonable than requiring vlserver to be up). But having other services accept GSSNegotiate calls I could maybe see, though: for example, if for whatever reason you can't talk to bosserver or vlserver, you can still do authenticated actions on ptserver. That doesn't strike me as terribly common, though, so it doesn't seem like a great concern. Maybe it could be optional? -- Andrew Deason [email protected] _______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
