[krbdev.mit.edu #6848] gss library minor status codes are not exposed

Arlene Berry via RT rt-comment at krbdev.mit.edu
Tue Feb 1 13:30:44 EST 2011


Actually, if you're not using SPNEGO and the status codes are unique
then mechanism codes such as those for Kerberos are returned.  Your
dynamic map only changes the codes if they've already been recorded for
another mechanism.  

You've got a separate issue with SPNEGO which is related to #6604.  When
using SPNEGO and a mechanism such as Kerberos reports an error, the
codes are always remapped.  The calling sequence is mechglue, spnego,
mechglue, kerberos.  The mechglue above kerberos maps the original code
as kerberos and the mechglue above spnego records it again as spnego
which forces a renumber.  The problem is that a calling application
cannot respond in any meaningful way.  We had to put a hack in to stop
the double recording so that we can detect things like clock skew,
expired credentials, and a specific situation with Microsoft's read only
domain controllers.  We'ld far rather have the original mechanism code
and risk duplicates than have a fake code we can't interpret.

-----Original Message-----
From: Greg Hudson via RT [mailto:rt-comment at krbdev.mit.edu] 
Sent: Tuesday, February 01, 2011 9:24 AM
To: Arlene Berry
Subject: [krbdev.mit.edu #6848] gss library minor status codes are not
exposed 

We don't actually return those minor codes directly, do we?  We map the 
error into a dynamic map so that different mechanisms can have 
overlapping internal error codes.

Perhaps we might be able to handle your specific need differently, but 
simply exposing the error codes doesn't seem like it will work.





More information about the krb5-bugs mailing list