Detecting user cancel in gss_init_sec_context

Miro Jurisic meeroh at
Wed Sep 24 11:53:13 EDT 2003

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.

>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 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).

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.


<> | KB1FMP

A: Because it reverses the logical flow of conversation.
Q: Why is top posting frowned upon?

More information about the krbdev mailing list