From bjaspan@MIT.EDU Tue Sep 24 16:30:00 1996
Received: from dragons-lair.MIT.EDU (DRAGONS-LAIR.MIT.EDU [18.177.1.200]) by avalanche-breakdown.MIT.EDU (8.7.5/8.7.3) with SMTP id QAA19993 for <bugs@AVALANCHE-BREAKDOWN.MIT.EDU>; Tue, 24 Sep 1996 16:29:59 -0400
Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by dragons-lair.MIT.EDU (8.6.13/8.6.9) with SMTP id QAA12986 for <krb5-bugs@dragons-lair.mit.edu>; Tue, 24 Sep 1996 16:29:58 -0400
Received: from DUN-DUN-NOODLES.MIT.EDU by MIT.EDU with SMTP
id AA18226; Tue, 24 Sep 96 16:29:55 EDT
Received: by DUN-DUN-NOODLES.MIT.EDU (5.x/4.7) id AA01378; Tue, 24 Sep 1996 16:29:47 -0400
Message-Id: <9609242029.AA01378@DUN-DUN-NOODLES.MIT.EDU>
Date: Tue, 24 Sep 1996 16:29:47 -0400
From: bjaspan@MIT.EDU
Reply-To: bjaspan@MIT.EDU
To: krb5-bugs@MIT.EDU
Subject: kadmind should syslog GSS-API errors from the RPC layer
X-Send-Pr-Version: 3.99
System: SunOS DUN-DUN-NOODLES 5.4 Generic_101945-37 sun4m sparc
kadmind should syslog GSS-API errors from the RPC layer, rather than
just "internal error." This will require a new callback function.
Responsible-Changed-From-To: hartmans->bjaspan
Responsible-Changed-By: bjaspan
Responsible-Changed-When: Tue Sep 24 16:45:24 1996
Responsible-Changed-Why:
State-Changed-From-To: open-closed
State-Changed-By: bjaspan
State-Changed-When: Wed Oct 16 15:17:22 1996
State-Changed-Why:
The probability of errors after the context is accepted is very small
and generally will indicate a code problem, not a configuration
problem; thus it is reasonable to have to see the debugging
information to get details. kadmind was only logging "internal error"
because gss_accept_sec_context had a bug in which it was not returning
CREDENTIALS_EXPIRED when that was in fact the case; accept_sec_context
is fixed, so that should no longer happen.
The only other case I can think of in which this can happen is when a
context during the processing of a single call, after it has already
been checked for expiration. That is pretty unlikely, and in any
event won't happen often.
Received: from dragons-lair.MIT.EDU (DRAGONS-LAIR.MIT.EDU [18.177.1.200]) by avalanche-breakdown.MIT.EDU (8.7.5/8.7.3) with SMTP id QAA19993 for <bugs@AVALANCHE-BREAKDOWN.MIT.EDU>; Tue, 24 Sep 1996 16:29:59 -0400
Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by dragons-lair.MIT.EDU (8.6.13/8.6.9) with SMTP id QAA12986 for <krb5-bugs@dragons-lair.mit.edu>; Tue, 24 Sep 1996 16:29:58 -0400
Received: from DUN-DUN-NOODLES.MIT.EDU by MIT.EDU with SMTP
id AA18226; Tue, 24 Sep 96 16:29:55 EDT
Received: by DUN-DUN-NOODLES.MIT.EDU (5.x/4.7) id AA01378; Tue, 24 Sep 1996 16:29:47 -0400
Message-Id: <9609242029.AA01378@DUN-DUN-NOODLES.MIT.EDU>
Date: Tue, 24 Sep 1996 16:29:47 -0400
From: bjaspan@MIT.EDU
Reply-To: bjaspan@MIT.EDU
To: krb5-bugs@MIT.EDU
Subject: kadmind should syslog GSS-API errors from the RPC layer
X-Send-Pr-Version: 3.99
Show quoted text
>Number: 19
>Category: krb5-admin
>Synopsis: kadmind should syslog GSS-API errors from the RPC layer
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: bjaspan
>State: closed
>Class: sw-bug
>Submitter-Id: unknown
>Arrival-Date: Tue Sep e 16:35:02 EDT 1996
>Last-Modified: Wed Oct e 15:20:06 EDT 1996
>Originator: Barry Jaspan
>Organization:
mit>Category: krb5-admin
>Synopsis: kadmind should syslog GSS-API errors from the RPC layer
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: bjaspan
>State: closed
>Class: sw-bug
>Submitter-Id: unknown
>Arrival-Date: Tue Sep e 16:35:02 EDT 1996
>Last-Modified: Wed Oct e 15:20:06 EDT 1996
>Originator: Barry Jaspan
>Organization:
Show quoted text
>Release: unknown-1.0
>Environment:
>Environment:
System: SunOS DUN-DUN-NOODLES 5.4 Generic_101945-37 sun4m sparc
Show quoted text
>Description:
kadmind should syslog GSS-API errors from the RPC layer, rather than
just "internal error." This will require a new callback function.
Show quoted text
>How-To-Repeat:
Show quoted text
>Fix:
Show quoted text
>Audit-Trail:
Responsible-Changed-From-To: hartmans->bjaspan
Responsible-Changed-By: bjaspan
Responsible-Changed-When: Tue Sep 24 16:45:24 1996
Responsible-Changed-Why:
State-Changed-From-To: open-closed
State-Changed-By: bjaspan
State-Changed-When: Wed Oct 16 15:17:22 1996
State-Changed-Why:
The probability of errors after the context is accepted is very small
and generally will indicate a code problem, not a configuration
problem; thus it is reasonable to have to see the debugging
information to get details. kadmind was only logging "internal error"
because gss_accept_sec_context had a bug in which it was not returning
CREDENTIALS_EXPIRED when that was in fact the case; accept_sec_context
is fixed, so that should no longer happen.
The only other case I can think of in which this can happen is when a
context during the processing of a single call, after it has already
been checked for expiration. That is pretty unlikely, and in any
event won't happen often.
Show quoted text
>Unformatted: