[33692] in Kerberos
Re: KDC TGS_REQ ticket expired log message has no client or server
daemon@ATHENA.MIT.EDU (Chris Hecker)
Thu Jul 28 19:19:44 2011
Message-ID: <4E31EE89.7010207@d6.com>
Date: Thu, 28 Jul 2011 16:19:37 -0700
From: Chris Hecker <checker@d6.com>
MIME-Version: 1.0
To: "kerberos@mit.edu" <kerberos@mit.edu>
In-Reply-To: <4E312FBF.8050001@d6.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
Hmm, digging deeper, the krb5_rd_req_decoded(_anyflag) functions are in
k5-int.h, and are only called from a couple places throughout all the
code. I could easily have them leave client even on failure, if I
documented that the caller needed to free it if it's non-null, and fixed
the couple of call sites. Since it's internal, I assume other people
outside krb5 aren't calling it (or deserve what they get :), and so
would a change like this be acceptible? It would change the error below to:
> Jul 28 04:28:17 example.com krb5kdc[14031](info): TGS_REQ (1 etypes
> {18}) 1.1.1.1: PROCESS_TGS: authtime 0, a@FOO.COM for
> <unknown server>, Ticket expired
for no performance penalty at all, which seems like a win for debugging
and security?
Chris
On 2011/07/28 02:45, Chris Hecker wrote:
>
> A typical failed TGS_REQ for an expired ticket looks like this:
>
> Jul 28 04:28:17 example.com krb5kdc[14031](info): TGS_REQ (1 etypes
> {18}) 1.1.1.1: PROCESS_TGS: authtime 0, <unknown client> for <unknown
> server>, Ticket expired
>
> This is slightly less than useful for finding which client is submitting
> expired TGTs.
>
> rd_req_decoded_opt computes the enc_part2->client, but then immediately
> toasts it on error out.
>
> It's pretty deep down so I guess it'd be a pain to fix, but it's a
> shame, since the information for a good error is computed, it's just
> thrown away too early.
>
> Thoughts?
>
> Chris
>
>
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
