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 ; 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 ; 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 >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 >Release: unknown-1.0 >Environment: System: SunOS DUN-DUN-NOODLES 5.4 Generic_101945-37 sun4m sparc >Description: kadmind should syslog GSS-API errors from the RPC layer, rather than just "internal error." This will require a new callback function. >How-To-Repeat: >Fix: >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. >Unformatted: