(Responding to the list since this seems like a interesting issue.)
nisse(a)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