Patch to ignore service principals when accepting connexions.
ghudson at MIT.EDU
Thu Aug 26 12:00:27 EDT 2010
On Wed, 2010-08-25 at 21:40 -0400, Roland C. Dowdeswell wrote:
> Is my proposed name ``check-service-instance'' reasonable or should
> we settle on another name?
How about "ignore-server-hostname"? Your patch, incidentally, only
seemed to include configuration logic, not the actual implementation of
the flag (looking at
Here's a wide-ranging response:
Case 1: GSS acceptors who use GSS_C_NO_CREDENTIAL (or acquire a cred
with GSS_C_NO_NAME), or krb5 acceptors who pass a null server to
These acceptors get nicely liberal acceptor behavior. Unfortunately,
it's difficult or impossible for GSS acceptors to find out what
host-based service was actually used in this case. (See
following for a little more discussion of this.) I don't have a
proposal for making this easier.
Case 2: GSS acceptors who import a host-based name but do not specify a
hostname, or krb5 acceptors who call krb5_sname_to_principal with a null
For these acceptors, krb5_sname_to_principal constructs a principal
"<service>/<localhostname>@<realm>", where <localhostname> is the
DNS-canonicalized result of gethostname() and <realm> is the
host-to-realm result of that hostname using only local configuration (or
the referral realm, aka the empty string, if that realm is
indeterminate). The keytab must contain an entry for
<service>/<localhostname>@<realm> (or ...@<default-realm> if <realm> is
the referral realm); the client may use any service principal which
matches that keytab entry's key.
I think acceptors in this class should, without any configuration
required, allow any hostname and any realm that the keytab can support.
For an implementation strategy, I tentatively propose that
krb5_sname_to_principal should construct a principal <service>/@, where
both the second component and realm name are empty. krb5_rd_req would
interpret this principal check against every two-component principal in
the keytab whose first component matches <service>. The ugly part: the
caller of krb5_sname_to_principal could also be an initiator trying to
talk to a local service, so krb5_get_credentials() would also have to be
able to handle <service>/@ principals.
Case 3: GSS acceptors who import a host-based name with a hostname, or
krb5 acceptors who call krb5_sname_to_principal with a non-null hostname
Roland wants (and Sam supports) a configuration variable which assumes
the app-provided hostname is bogus for acceptors and should be ignored,
at which point we want behavior equivalent to case 2.
The implementation strategy has to be different from what I propose for
case 2. krb5_sname_to_principal can't throw out the hostname, because
the caller might be an initiator. So I think the configuration variable
would have to be checked in krb5_rd_req, which would then throw out the
second component of host-based principals and match any hostname.
Disclaimers: Currently my schedule for the 1.9 release is tight. I'm
not volunteering to implement any of this. I can't even guarantee that
I'll have time to review and integrate a patch for 1.9, though I'll try.
I'm not insisting that case 2 and case 3 be implemented at the same
More information about the krbdev