bind KDC to single interface?

Ken Raeburn raeburn at MIT.EDU
Thu Feb 25 20:01:08 EST 2010


On Feb 25, 2010, at 12:12, Abe Singer wrote:
> I'll give you a reason for why I need it.  I'm trying to fire up
> krb5kdbc listening on a virtual interface on a host where there's another
> process (not krb5kdc) listening on the same port on other interfaces.

That makes sense, thanks; though I'm curious what other software wants the privileged port assigned to Kerberos.  (Actually, the KDC grabs two privileged ports by default, 88 and 750, and I don't know if 750 is assigned by IANA, but my /etc/services lists other services for it.  It's there for Kerberos v4 support, and probably should be dropped from the current release now that the v4 support has been deleted.)

> I'm sure that at least some of the other people who ask have some other
> valid reason for doing so.

Oh, I'm sure at least some do, and we should eventually support it; I just don't think I've heard the reasons.  And strictly speaking, I don't need to, but I'm curious. :-)

> As for binding a socket on each separate address, the syslog messages
> from krb5kdc indicate that it is already doing just that for UDP (see below).

Yes, like I said, it depends on system attributes.  If it could do what it needs to with one UDP socket on 0.0.0.0, it would do it that way, but it can't, so it grabs all addresses; that's just how it's written at the moment.  (There's even code in the current sources to -- at least on some systems -- monitor the routing table to try to figure out when interfaces or addresses are added and removed, and reconfigure if necessary.)

> There's just no feature to restrict which of those get bound.

Nope. :-(  I've been poking at some of the related code recently in my private development tree; maybe I'll get around to fixing this sometime soon and submit it upstream.  (The code for dealing with this is duplicated in the KDC and kadmind code, which should probably be unified; that would make it easier to make the same change to kadmind, too.)

Ken



More information about the Kerberos mailing list