On Tue, 2013-02-12 at 20:55 +0000, Chaskiel Grundman wrote: > > [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. > > Interpreting this as actual machines makes the most sense here.
Operationally, maybe, but in terms of code structure and the way server implementations work, I think not. The idea here is that if you obtain an rxgk token from, say, a vlserver, you can use it to talk to that vlserver. You can also use it to talk to other vlservers and to the other database services, because those services pretty much have to be centrally managed and already have to share keys, so having them able to interpret each others' tokens is not a hardship. Doing it that way makes life a lot easier given the existing AFS client architecture, because it allows all the GSS bits to stay in aklog or whatever, and doesn't require preemptively getting tokens for every dbserver in order to make sure you'll have one for whichever server happens to still be up when you want to do an operation. Fileservers, on the other hand, are a different beast. The idea is that whenever you talk to a specific fileserver, you get a token for that server. But, you get it via AFSCombineTokens, rather than from scratch, because that means the CM doesn't have to have the client's original credentials around or else know up front what all the possible fileservers are. For consistency in both CM and server implementations, it's better if this model applies even to fileservers which happen to be on the same machine as a database service. In fact, it's better to avoid thinking too hard about "machines". A fileserver is reachable at the address(es) (and, eventually, ports) the vlserver advertises. Those might be the same as some address by which the vlserver itself is reachable, but I see no reason to conflate those (certainly, on the implementation side, processes co-located on the same machine might end up using the same key). Further, requiring combined tokens for all fileserver accesses means that the vlserver has the opportunity to inject additional authorization information or whatever into the tokens it creates. We might not have a use for that today, but if we ever did, it would be nice to be able to depend on clients always doing it. Finally, I think the rule as it applies to fileservers also needs to apply to volservers. Among other things... > One of the > purposes for all this complexity is so that fileserver machines (running > bosserver, fileserver and volserver processes) can have unique keys not > shared with all the other server hosts in the cell. This is somewhat simpler > administratively, but also enables a cell to have servers administered by > multiple groups that don't trust each other (everyone must trust the > database server maintainers, but that's it) And if that's the case, then you need a server-specific token to talk to a volserver. I'm not sure what to do about the bosserver. It's really more of a management tool than part of the main protocol suite. It seems like, at a minimum, it ought to be possible to obtain a token for a given bosserver by negotiating directly with that server, the same as for any other rxgk service. Arguably the same should be possible for volservers and maybe even fileservers, though in practice that doesn't seem as useful. -- Jeff _______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
