Re: Bug? kadmind binds only to IPv6 addresses, if IPv6 is enabled

["Torsten Kurbad" <torsten@tk-webart.de>]

From: "Love" <lha@stacken.kth.se>

>> It seems that kadmind binds to *:749/tcp, which causes an IPv6 enabled
linux
>> host to insist that 749/tcp is already bound even for IPv4.
>> By starting kadmind with the -d option it will report that the socket is
>> already bound for af=2.

> last time I checked, linux also answered ipv6 used ipv4 mapped addresses
> for ipv6 sockets, so, didn't it just work ?

Nope, if it would simply work, I wouldn't complain... ;o)

IMO, to have the functionality you mentioned above, it is necessary to
activate IPv6 in IPv4 tunneling, which isn't always what you want...

>> Would it be difficult to enhance kadmind in that way?

> Not really, just need to share code between kadmind and kdc, but isn't it
> easier to start kadmind from inetd ?
> [excerpt from documentation]

This was the first thing I tried and it didn't work either (that's why I
even came to the idea to let kadmind run on its own). We use xinetd, btw.
The thing is that xinetd (like the "old fashioned" inetd) only allows a weak
kind of access control to certain services, i.e. does allow/deny access for
requests from different subnets, but doesn't really care about binding to
special addresses. And if you can only specify a port on an IPv6 enabled
machine, this port is bound for all types of addresses. So, the same problem
again...

Apart from that, running services from xinetd is not really what I prefer,
since we have amanda running as a backup service on the same machine and if
something kills xinetd, amanda dies with it... ;o(

Also, you cited a phrase that caught my attention (although nobody explains
it any further) that it's not recommended to start kadmind from inetd.

Eventually, I'll try to write a patch for kadmind on my own and suggest it
here for further discussions...

Regards,
Torsten