> I assume you mean krb5_rd_req_decoded would set the ticket output > value in cases where it decrypts and decodes successfully but > doesn't validate?
Yeah, and the caller would be responsible for calling krb5_free_enc_tkt_part if the ticket is non-null instead of it being called in cleanup: at the bottom of rd_req_decoded_opt. It's only called in a couple places, and the more public and common krb5_rd_req could just delete it on failure to stay compatible. > I think it would be possible to log the server name as well, since > that's just sitting in the request structure. I know that's less > interesting to you. That'd be great, the more detailed logging the better, especially if it's free! Chris On 2011/08/07 22:54, Greg Hudson wrote: > On Thu, 2011-07-28 at 19:19 -0400, Chris Hecker wrote: >> 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 > > I assume you mean krb5_rd_req_decoded would set the ticket output value > in cases where it decrypts and decodes successfully but doesn't > validate? I think that would be acceptable, and there even seems to be > KDC code to handle this case. > > I think it would be possible to log the server name as well, since > that's just sitting in the request structure. I know that's less > interesting to you. > > > ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
