krb5-libs/1022: accept_sec_context() specifies principal to rd_req()

[Donn Cave]

Quoth Sam Hartman <hartmans at mit.edu>:
| >>>>> "Nicolas" == Nicolas Williams <Nicolas.Williams at ubsw.com> writes:
|
|     Nicolas> Why not use the default credential, GSS_C_NO_CREDENTIAL
|     Nicolas> and then inquire the context for the acceptor name?
|
| I don't think our implementation supports this.

True, but apparently by accident - in 1.2.3, anyway, krb5_gss_validate_cred()
is applied to verifier_cred_handle (GSS_C_NO_CREDENTIAL) instead of
cred_handle (acquired by default in this case), so it's guaranteed to
fail.  Maybe I misunderstand the point, but I'd change it to

*** 270,270 ****
!    major_status = krb5_gss_validate_cred(&code, verifier_cred_handle);
--- 270,270 ----
!    major_status = krb5_gss_validate_cred(&code, cred_handle);


| I argue that this is
| the correct solution and am leaving the bug open in the hope that
| someone (either at MIT or in the larger community) will get around to
| writing such support.


How about this, fix the above problem and then pass the name to rd_req()
only if the input credentials weren't GSS_C_NO_CREDENTIAL?

*** 347,350 ****

!    if ((code = krb5_rd_req(context, &auth_context, &ap_req, cred->princ,
!                          cred->keytab, NULL, &ticket))) {
         major_status = GSS_S_FAILURE;
--- 347,351 ----

!    if ((code = krb5_rd_req(context, &auth_context, &ap_req,
!               verifier_cred_handle == GSS_C_NO_CREDENTIAL ? NULL : cred->princ,
!               cred->keytab, NULL, &ticket))) {
         major_status = GSS_S_FAILURE;

That allows an application to decide its own policy.  The application
gets this freedom by supplying GSS_C_NO_CREDENTIAL, which we can safely
assume no existing application does.

	Donn Cave, University Computing Services, University of Washington
	donn at u.washington.edu