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
________________________________________________
Kerberos mailing list           [email protected]
https://mailman.mit.edu/mailman/listinfo/kerberos

Reply via email to