RT RT/krbdev.mit.edu: Ticket #7045 SPNEGO can't display mechanism errors Signed in as guest.
[Logout]

[Home] [Search] [Configuration]

[Display] [History] [Basics] [Dates] [People] [Links] [Jumbo]

 
 

 The Basics  
Id
7045
Status
new
Worked
0 min
Priority
0/0
Queue
krb5
 

 Keyword Selections  
Component
Version_reported
Version_Fixed
Target_Version
Tags
 

 Relationships  
Depends on:
Depended on by:
Parents:
Children:

Refers to:
Referred to by:
 
 Dates  
Created: Wed Dec 7 13:07:21 2011
Starts: Not set
Started: Not set
Last Contact: Not set
Due: Not set
Updated: Wed Dec 7 13:07:21 2011 by ghudson
 

 People  
Owner
 Nobody
Requestors
 ghudson@mit.edu
Cc
 
AdminCc
 
 

 More about Greg Hudson  
Comments about this user:
No comment entered about this user
This user's 25 highest priority tickets:
 

History   Display mode: [Brief headers] [Full headers]
      Wed Dec  7 13:07:21 2011  ghudson - Ticket created    
     
Subject: SPNEGO can't display mechanism errors

If SPNEGO makes a call to an underlying mechanism and it fails, SPNEGO
passes the minor status it received back down into the mechglue.  The
mechglue maps the mech OID and status to a new value (like 100005) and
returns it to the app.

When the app calls gss_display_status on this value, the mechglue
faithfully unmaps it to SPNEGO and the underlying minor code, and calls
spnego_gss_display_status.  But that function only knows how to display
SPNEGO-specific error codes, and returns an empty string for anything
else.

The simple solution would be for spnego_gss_display_status to
recursively call gss_display_status on unrecognized codes.  That
solution runs the risk of blowing the stack if, for some reason,
gss_display_status winds up calling back into spnego_gss_display_status
with the same code.  There are ways to eliminate this risk (a thread-
specific variable remembering if we've already called into
spnego_gss_display_status, or a SPNEGO-spceific minor status map), but
they're complicated.


Download (untitled) 1020b