(Responding to the list since this seems like a interesting issue.)
nisse@lysator.liu.se (Niels Möller) writes:
Oops, I didn't think of this. OK, it seems fairly clear that GSS should be invoked from a different process, which communicate with the lsh core using some protocol, then. Still, since kerberos 5 GSS mechanism is fast, this is probably not a show-stopper. I think I'll leave this as an exercise.
As long as the servers contacted are *not* of the user's/client's choice, it may be ok.
For the Kerberos 5 GSS mechanism, the server doesn't talk to the network, at least my K5 implementation doesn't. But in general, there is no such guarantee, and GSS_Accept_sec_context is even specifically allowed to block:
This call may block pending network interactions for those mech_types in which a directory service or other network entity must be consulted on behalf of a context acceptor in order to validate a received input_token.
Is there any chance of an non-blocking variant of the gss-api?
Generally speaking, that is up to the IETF. Searching for "block" in the RFCs suggest people haven't thought about this. Which is symptomatic of many things in GSS; I'll add this problem to my Criticism of GSS section.
It may be possible to support a new extension flag to request only non-blocking mechanisms, but existing GSS libraries wouldn't support it. I'll think about adding this for my GSS library.
It's often painful to write proper select-loop based programs, because various libraries one want to use are blocking. Most common example is gethostbyname, select-loop based programs have to either not use DNS, or fork a separate process for DNS lookups, or use some non-blocking resolver library, like adns. It would be nice with some adns-like interface to gss-api or directly to kerberos, but I'm not aware of any work in that direction.
Neither am I. It sounds like it would be possible to implement this in a wrapper library though, a'la
handle = START(gss_accept_sec_context(...)) gss_call_started = now() do select loop if FINISHED(handle) maj_stat = FINISH(handle) continue GSS operation... if gss_call_started < now() - 10000 ABORT(handle) send gss error...
The START function would start the operation in another process, FINISHED would check if the function call has finished, and FINISH would clean up the operation and return the function value, and ABORT would cleanup the operation without caring about the return value.
There could be some tricky issues -- e.g., what if you call ABORT and the process later do return something useful, then the GSS state is probably in an undefined state from the application's point of view -- but it doesn't look infeasible.
It could perhaps even be implemted as a meta-gss library, similar to adns. Hm.
OTOH, I recall you mentioned LSH might support a separated process style authentication in the future anyway, so then the GSS calls can be moved to that second process. This would probably be simpler. It would also simplify binary packaging -- only the second process need to be different for GSS, the core lshd is the same.
Regards, Simon