Skip Menu |
 

Date: Fri, 11 Nov 2005 21:05:06 +0100
From: Christophe Nowicki <cscm@meuh.dyndns.org>
To: krb5-bugs@mit.edu
Subject: Kerberos does not work inside Linux vservers
Download (untitled) / with headers
text/plain 1.7KiB
Hi,

I'am trying to make kerberos working inside a Linux Vserver
(http://linux-vserver.org/). Am using debian's version 1.3.6-5 of
kerberos.

My vserver has many network interfaces :

#/sbin/ifconfig

eth0 Link encap:Ethernet HWaddr 00:40:63:DC:ED:EE
inet addr:192.168.42.1 Bcast:192.168.42.255
Mask:255.255.255.0
...

eth0:cact Link encap:Ethernet HWaddr 00:40:63:DC:ED:EE
inet addr:192.168.42.21 Bcast:192.168.42.255
Mask:255.255.255.0
...

eth0:kdc Link encap:Ethernet HWaddr 00:40:63:DC:ED:EE
inet addr:192.168.42.27 Bcast:192.168.42.255
Mask:255.255.255.0
...

With the vserveur patch, programs are not able to bind to thoses
interfaces. There can bind only the current vserver interface
(192.168.42.27 in this case).

But krb5kdc, try to bind on *EVERY* network interface avalide :

Nov 11 19:39:08 kdc krb5kdc[13311]: setting up network...
Nov 11 19:39:08 kdc krb5kdc[13311]: skipping unrecognized local address
family 17
Nov 11 19:39:08 kdc krb5kdc[13311]: Cannot assign requested address -
Cannot bind server socket to port 88 address 192.168.42.1
^ this is the first network
interface
Nov 11 19:39:08 kdc krb5kdc[13311]: set up 0 sockets
Nov 11 19:39:08 kdc krb5kdc[13311]: no sockets set up?

krb5kdc fail to start.

I suggest to allow users to bind krb5kdc server on a specific
interface with the addresses directive in the kdcdefaults section of
the kdc.conf file, like that:

[kdcdefaults]
kdc_ports = 750,88
addresses = 192.168.42.27

Best Regards,

--
Nowicki Christophe
EPITECH Promo 2006
http://people.easter-eggs.org/~cnowicki/
Download signature.asc
application/pgp-signature 189B

Message body not shown because it is not plain text.

Download (untitled) / with headers
text/plain 1.1KiB
Show quoted text
> I'am trying to make kerberos working inside a Linux Vserver
> (http://linux-vserver.org/). Am using debian's version 1.3.6-5 of
> kerberos.

I have no idea how the vserver code alters the environment that would
affect the Kerberos code's ability to see the local addresses it's
allowed to use. Would you mind fetching and building 1.4.2 (or the
1.4.3 beta) from our web site (web.mit.edu/kerberos) and seeing if it
has the same problem? Once you've built and installed it, you can also
go into src/lib/krb5/os in your build tree and run "make t_localaddr"
and "./t_localaddr"; that'll print some debug information while trying
to look up the addresses on the network interfaces. (Depending on the
version of Linux, glibc, etc., it either uses a C library call that's
supposed to get them, or uses a bunch of fairly standard ioctl calls
that usually do the right thing, but maybe that bit needs tweaking for
vserver support.)


Show quoted text
> I suggest to allow users to bind krb5kdc server on a specific
> interface with the addresses directive in the kdcdefaults section of
> the kdc.conf file, like that:

That might be a good idea, but we still need to solve the problem above.
Date: Wed, 16 Nov 2005 23:12:22 +0100
From: Christophe Nowicki <cscm@meuh.dyndns.org>
To: Ken Raeburn via RT <rt-comment@krbdev.mit.edu>
Subject: Re: [krbdev.mit.edu #3237] Kerberos does not work inside Linux vservers
RT-Send-Cc:
Download (untitled) / with headers
text/plain 2.1KiB
On Tue, Nov 15, 2005 at 09:08:20PM -0500, Ken Raeburn via RT wrote:
Show quoted text
> > I'am trying to make kerberos working inside a Linux Vserver
> > (http://linux-vserver.org/). Am using debian's version 1.3.6-5 of
> > kerberos.
>
> I have no idea how the vserver code alters the environment that would
> affect the Kerberos code's ability to see the local addresses it's
> allowed to use. Would you mind fetching and building 1.4.2 (or the
> 1.4.3 beta) from our web site (web.mit.edu/kerberos) and seeing if it
> has the same problem?
I've build version 1.4.2.
Show quoted text
> Once you've built and installed it, you can also
> go into src/lib/krb5/os in your build tree and run "make t_localaddr"
> and "./t_localaddr";
Here is the output :
kdc:~/krb5-1.4.2/src/lib/krb5/os# ./t_localaddr
--> family 17 <getnameinfo error -6: ai_family not supported>
--> family 2 addr 192.168.42.1
--> family 2 addr 192.168.42.21
--> family 2 addr 192.168.42.15
--> family 2 addr 192.168.42.62
--> family 2 addr 192.168.42.27
--> family 2 addr 192.168.42.18
--> family 2 addr 192.168.42.13
--> family 2 addr 192.168.42.22
--> family 2 addr 192.168.42.17
--> family 2 addr 192.168.42.14
--> family 2 addr 192.168.42.6
return value = 0

The first interfaces (--> family 17 <getnameinfo error -6: ai_family not supported>)
Seams to be the loopback interface.

Show quoted text
> that'll print some debug information while trying
> to look up the addresses on the network interfaces. (Depending on the
> version of Linux, glibc, etc., it either uses a C library call that's
> supposed to get them, or uses a bunch of fairly standard ioctl calls
> that usually do the right thing, but maybe that bit needs tweaking for
> vserver support.)
>
>
> > I suggest to allow users to bind krb5kdc server on a specific
> > interface with the addresses directive in the kdcdefaults section of
> > the kdc.conf file, like that:
>
> That might be a good idea, but we still need to solve the problem above.
If you need more help/informations, just ask.

Best Regards,
Show quoted text
>

--
Nowicki Christophe
EPITECH Promo 2006
http://people.easter-eggs.org/~cnowicki/
Download signature.asc
application/pgp-signature 189B

Message body not shown because it is not plain text.

From: Ken Raeburn <raeburn@MIT.EDU>
Subject: Re: [krbdev.mit.edu #3237] Kerberos does not work inside Linux vservers
Date: Wed, 16 Nov 2005 19:15:55 -0500
To: rt-comment@krbdev.mit.edu
RT-Send-Cc:
On Nov 16, 2005, at 17:07, Christophe Nowicki via RT wrote:
Show quoted text
> Here is the output :

Thanks! That output looks good. Well, maybe... did you run it in
the same vserver environment that the KDC would run in? I'm guessing
that, in that case, we would only want to return one address. It
sort of depends -- does the vserver environment hide the other
addresses, or just not permit you access to them?

If you run the 1.4.2 KDC in the vserver environment, does it bind to
the correct addresses?

Show quoted text
> The first interfaces (--> family 17 <getnameinfo error -6:
> ai_family not supported>)
> Seams to be the loopback interface.

According to my Linux system headers, it's the "packet family"
address type, which I'm not at all familiar with.

The loopback interface should be probed, the "loopback" flag found,
and the address dropped from the list before it's printed. (Maybe I
should've had you turn on the DEBUG flag when building, that might've
produced a little more output. Though looking at the code, there's
one major path where DEBUG doesn't add anything.)

Ken
Download (untitled) / with headers
text/plain 1.3KiB
I'm sorry about the delay in getting back to you -- I accidentally sent
my reply to the email address for filing the response with the bug
report but *not* sending a copy back to the original reporter of the
problem, and didn't notice for quite some time....

Show quoted text
> > Here is the output :
>
> Thanks! That output looks good. Well, maybe... did you run it in
> the same vserver environment that the KDC would run in? I'm guessing
> that, in that case, we would only want to return one address. It
> sort of depends -- does the vserver environment hide the other
> addresses, or just not permit you access to them?
>
> If you run the 1.4.2 KDC in the vserver environment, does it bind to
> the correct addresses?
>
> > The first interfaces (--> family 17 <getnameinfo error -6:
> > ai_family not supported>)
> > Seams to be the loopback interface.
>
> According to my Linux system headers, it's the "packet family"
> address type, which I'm not at all familiar with.
>
> The loopback interface should be probed, the "loopback" flag found,
> and the address dropped from the list before it's printed. (Maybe I
> should've had you turn on the DEBUG flag when building, that might've
> produced a little more output. Though looking at the code, there's
> one major path where DEBUG doesn't add anything.)
>
> Ken
From: cscm@meuh.dyndns.org
Date: Sun, 25 Jun 2006 00:15:44 +0200 (CEST)
Subject: Re: [krbdev.mit.edu #3237] Kerberos does not work inside Linux vservers
To: rt-comment@krbdev.mit.edu
RT-Send-Cc:
Download (untitled) / with headers
text/plain 2.5KiB
Hi Ken,

Show quoted text
> I'm sorry about the delay in getting back to you -- I accidentally sent
> my reply to the email address for filing the response with the bug
> report but *not* sending a copy back to the original reporter of the
> problem, and didn't notice for quite some time....
No problem.

Show quoted text
>> > Here is the output :
>>
>> Thanks! That output looks good. Well, maybe... did you run it in
>> the same vserver environment that the KDC would run in?
Yes,
Show quoted text
>> I'm guessing
>> that, in that case, we would only want to return one address. It
>> sort of depends -- does the vserver environment hide the other
>> addresses, or just not permit you access to them?
The vserver does not hide the other interfaces :
#/sbin/ifconfig
eth0 Link encap:Ethernet HWaddr 00:11:95:25:DB:0C
inet addr:192.168.42.1 Bcast:192.168.42.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:48066286 errors:0 dropped:0 overruns:0 frame:0
TX packets:51623403 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:196681514 (187.5 MiB) TX bytes:471795406 (449.9 MiB)
Interrupt:177 Base address:0xc00

eth0:cact Link encap:Ethernet HWaddr 00:11:95:25:DB:0C
inet addr:192.168.42.21 Bcast:192.168.42.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Interrupt:177 Base address:0xc00

eth0:cfg Link encap:Ethernet HWaddr 00:11:95:25:DB:0C
inet addr:192.168.42.15 Bcast:192.168.42.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Interrupt:177 Base address:0xc00

eth0:dist Link encap:Ethernet HWaddr 00:11:95:25:DB:0C
inet addr:192.168.42.62 Bcast:192.168.42.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Interrupt:177 Base address:0xc00
...
But you can't bind on other interfaces,
If you process is running in vserver 'a' you can see interface of vserver
'b' but you can bind on b:88 (you can only bind on a:88).

The strange thin about kdc, is that he try to bind only on the first
interface and fail to setup network :

Jun 25 00:13:20 kdc krb5kdc[4311]: Cannot assign requested address -
Cannot bind server socket to port 88 address 192.168.42.1
Jun 25 00:13:20 kdc krb5kdc[4311]: set up 0 sockets
Jun 25 00:13:20 kdc krb5kdc[4311]: no sockets set up?


Show quoted text
>>
>> If you run the 1.4.2 KDC in the vserver environment, does it bind to
>> the correct addresses?
I've upgraded to KDC version 1.4.3.

Best Regards,