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

[Donn Cave]

Quoth Sam Hartman <hartmans at MIT.EDU>:

| This patch seems wrong because it ignores a principal name that was
| supplied.  It seems that allowing gss_accept_sec_context to work with
| a default credential (as gss_init_sec_context does), or to allow
| gss_acquire_creds to take a default name would be preferable to your proposed solution.
|
| I'd be interested in a patch to this problem, but I don't feel
| comfortable with a patch that throws away information from the
| application when it is supplied.  Just as krb5_rd_req has a fourth
| argument, GSSAPI should respect the service name when provided.

It turns out that we were able to solve our particular problem at our
site more easily in ftpd itself, by resolving the DNS name more accurately
as I suggested in the very next bug, krb5-appl/1023.  If that could be done,
then I'd have no stake in this issue.  In any case it isn't as important
as the GSS_C_NO_CHANNEL_BINDING support that Jeffrey Altman submitted some
time back for this file.

In principle, though, I don't see this as throwing away information.
The information in question is "who did I authenticate as", and that
is available in the context via gss_inquire_context().  (I think,
haven't verified that.)  The problem is that currently, krb5_rd_req()
goes on to turn this information into policy, at a level that's not
accessible to the application.  Like telnetd (which I believe checks
principal name minus instance), ftpd could enforce its own policy in
this matter, but it has to get past gss_accept_sec_context() first.

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