Detecting user cancel in gss_init_sec_context

[Alexandra Ellwood]

>At 4:58 PM -0400 9/17/2003, Alexandra Ellwood wrote:
>>>I am calling gss_acquire_cred and if the user has no tickets, the 
>>>login dialog comes up (so far so good). If the user cancels the 
>>>dialog, I get back maj_stat of 0x000D0000 and min stat of 
>>>-1765328189, which is KRB5_FCC_NOFILE. This is unfortunately very 
>>>unhelpful, as I am left with no choice but to present an error 
>>>dialog to the user, even though no error dialog should be 
>>>presented, given that the user knowingly canceled the login 
>>>dialog. Is there some way for me to reliably distinguish the case 
>>>where the user cancels from other Kerberos errors?
>>
>>No.  The login dialog errors are not returned by krb5 and GSS APIs 
>>because they are not part of either API specification.
>
>Of course, I am not asking for krb5 and GSSAPI to return a Kerberos 
>Login error; that would clearly be outside of the spec. I would like 
>there to be an error which unambiguously indicates that a krb5 call 
>failed because the user cancelled, especially given that on Panther 
>you are now introducing the ambiguity between KRB5_FCC_NOFILE 
>meaning user cancel and it meaning no tickets and no prompting.

There is no plan for this sort of enhancement.

In the future, automatic prompting will need to be phased out as more 
and more protocols start negotiating authentication with SASL, TLS 
and SPNEGO.  These authentication negotation mechanisms all call 
gss_init_sec_context() to see if Kerberos is available.  As a result, 
we will have to stop prompting on all calls to gss_init_sec_context() 
because otherwise the user will get harassed by the dialog even if 
they want to fall back on some other authentication method.

Once we make this change, applications wishing prompting will have to 
call into the KLL APIs if they want the dialog to appear when they 
have no tickets.  As a result, we have not been spending resources 
improving the existing automatic prompting support.

>>Given that the dialog may be on screen for a while or possibly 
>>generated when your application is in the background, I suspect 
>>that not reporting the error will confuse users.  I recommend 
>>reporting that the operation requires Kerberos in some sort of 
>>status area (like Eudora or Mail.app do) so that you don't annoy 
>>the user with a modal dialog.
>
>I am not sure what you mean by this. The dialog comes up in response 
>to the user trying to establish a new connection using GSSAPI. In 
>general, this will not cause the dialog to be up for a long time nor 
>will it happen when the application is in the background (the only 
>exception is if the user does it from a script).

Because the dialog is not system-modal (like it was on Mac OS 9), the 
user is free to ignore it and continue using other non-Kerberized 
applications.  On a machine with a decent sized monitor, the dialog 
isn't even particularly annoying.  I have certainly left it on the 
screen for up to an hour because I was busy doing something else and 
didn't care whether I got mail right away.

>It seems to me that adding a new krb5 error code which signals this 
>condition is the right solution, although I will look into using one 
>of your proposed workarounds.

Yes, it would be nice to get such an error with the existing 
behavior.  However, since neither Jaguar nor Panther will have it, I 
suspect that even if we added it for you in some later release, it 
still wouldn't be useful because you have to support older OSes.


Hope this helps,

--lxs
-- 
-----------------------------------------------------------------------------
Alexandra Ellwood                                               <lxs at mit.edu>
MIT Information Systems                               http://mit.edu/lxs/www/
-----------------------------------------------------------------------------
--