[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: kdc not binding correctly



I had simliar problems with heimdal 0.5.1 but got this fix from
John Godehn <godehn@email.unc.edu> that solved my problems:

>From godehn@email.unc.edu Mon Dec  9 13:26:07 2002
Date: Mon, 21 Oct 2002 15:42:30 -0400 (EDT)
From: John Godehn <godehn@email.unc.edu>
To: heimdal-discuss@sics.se
Subject: krb5_addr2sockaddr problems


Hello, when trying out Heimdal 0.5, I ran into some problems getting the
kpasswdd to start. I keep getting the following entry in the log file:

2002-10-21T13:43:52 socket: Addr family not supported by protocol

I seem to have tracked down the source of my problems to the
krb5_addr2sockaddr function and the functions that backend it, particularly
the ipv4_addr2sockaddr. It seems that in the newer version of Heimdal, the
meaning of the sa_size parameter has changed. In the older (0.4e) version,
it was strictly a out parameter indicating the size of the structure the
function filled. Now, the input for this paramter is used to determine the
maximum length of the structure to be filled.

Now the problem is that in places where this function is used
(kpasswd/kpasswdd.c and kdc/connect.c), the parameter isn't initialized:

kdc/connect.c:

static void
init_socket(struct descr *d, krb5_address *a, int family, int type, int port)
{
    krb5_error_code ret;
    struct sockaddr_storage __ss;
    struct sockaddr *sa = (struct sockaddr *)&__ss;
    int sa_size;

    init_descr (d);

    ret = krb5_addr2sockaddr (context, a, sa, &sa_size, port);

So since the sa_size isn't being initialized to sizeof(*sa), sometimes
the krb5_addr2sockaddr worked and sometimes it didn't, depending on what
sa_size happened to get initialized to. For example, under AIX 5.1, kpasswdd
would work if compiled with no optimization and fail it it was compiled with
optimization (since the stack was different and sa_size was initialized to 0)

So it seems as though kdc/connect.c and kpasswd/kpasswdd.c need to be
patched something like:

diff -ur heimdal-0.5.orig/kdc/connect.c heimdal-0.5/kdc/connect.c
--- heimdal-0.5.orig/kdc/connect.c      Mon Aug 12 09:29:48 2002
+++ heimdal-0.5/kdc/connect.c   Mon Oct 21 15:34:17 2002
@@ -236,7 +236,7 @@
     krb5_error_code ret;
     struct sockaddr_storage __ss;
     struct sockaddr *sa = (struct sockaddr *)&__ss;
-    int sa_size;
+    int sa_size = sizeof(*sa);

     init_descr (d);

diff -ur heimdal-0.5.orig/kpasswd/kpasswdd.c heimdal-0.5/kpasswd/kpasswdd.c
--- heimdal-0.5.orig/kpasswd/kpasswdd.c Mon Aug 19 11:07:31 2002
+++ heimdal-0.5/kpasswd/kpasswdd.c      Mon Oct 21 15:34:48 2002
@@ -448,7 +448,7 @@
     maxfd = -1;
     FD_ZERO(&real_fdset);
     for (i = 0; i < n; ++i) {
-       int sa_size ;
+       int sa_size = sizeof(*sa);

        krb5_addr2sockaddr (context, &addrs.val[i], sa, &sa_size, port);


if krb5_addr2sockaddr is going to have this new behavior. If I am mistaken,
please let me know.

Thanks,

John


On Mon, 9 Dec 2002, Gunnar Gunnarsson wrote:

> Hej,
> I'm testing heimdal version  (Heimdal 0.5.1, KTH-KRB 1.2.1) on Solaris
>  5.7  and I'm getting
>
> kpasswdd[1573]: socket: Protocol not supported when
>
> The other daemon seems to be working ( kdc and kadmind ).
>


Balazs GAL writes:
 > 2003-03-03, h keltez-Béssel Brian May ezt írta:-A
 > > I had a feeling I previously reported this, but then it come good or
 > > something.
 > > 
 > > ...well it has gone bad again ;-)
 > > 
 > > Heimdal 0.5.1, Debian version.
 >           
 > > tcp        0      0 226.106.44.64:512       0.0.0.0:*               LISTEN      12408/kdc
 > 
 >            
 > > bind(17, {sin_family=AF_INET, sin_port=htons(512), sin_addr=inet_addr("226.106.44.64")}}, 16) = -1 EADDRINUSE (Address already in use)
 > 
 > > Has anyone else experienced similar problems?
 > 
 > YES !!! This is my problem too.
 > 
 > (Heimdal 0.5.1, Debian version. ported to woody/sarge )
 > 
 > bind(4, {sin_family=AF_INET, sin_port=htons(8),
 > sin_addr=inet_addr("226.154.43.64")}}, 16) = 0
 >                     ^^^^^^^^^^^^^
 > 
 > and much worse it doesn't bind to 4444/tcp|udp etc.
 > 
 > Any idea?
 > 
 > The same binaries are working in other domain's well.
 > 
 > balsa
 >