[Bug 563] getaddrinfo() in libopenbsd-compat.a breaks heimdal-linked pam_krb5

[bugzilla-daemon at mindrot.org]

http://bugzilla.mindrot.org/show_bug.cgi?id=563

           Summary: getaddrinfo() in libopenbsd-compat.a breaks heimdal-
                    linked pam_krb5
           Product: Portable OpenSSH
           Version: -current
          Platform: Sparc
        OS/Version: Solaris
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Miscellaneous
        AssignedTo: openssh-unix-dev at mindrot.org
        ReportedBy: buckh at pobox.com


i realize that fake-getaddrinfo.c says, ``Don't use it for another purpose,''
but if getaddrinfo can't be renamed then stuff like this is inevitable, and i
think it might not just be me so i wanted to point it out:

heimdal uses the getaddrinfo()-returned ai_protocol, ai_socktype and ai_protocol
in its socket() call in send_to_kdc(), after passing in the desired ai_socktype
in hints->ai_socktype. on Solaris 2.6, there's no getaddrinfo(), so heimdal
builds this into it's libroken and ssh builds this into libopenbsd-compat. when
sshd goes to use pam_krb5 for keyboard-interactive, the pam_krb5 calls to
heimdal's libkrb5 result in libopenbsd-compat's getaddrinfo() getting called,
which always returns a struct addrinfo with ai_socktype == ai_protocol == 0, and
socket() buys an EPROTOTYPE:

send_to_kdc.c:
  ret = krb5_krbhst_get_addrinfo(context, hi, &ai);
  if (ret)
      continue;

  for (a = ai; a != NULL; a = a->ai_next) {
      fd = socket (a->ai_family, a->ai_socktype, a->ai_protocol);
      if (fd < 0)
          continue;

truss says:

  so_socket(2, 0, 0, 0x00000000, 1)               Err#98 EPROTOTYPE
       0x00000000: ""

(i have to admit i have absolutely no idea where it's getting ai_family from, if
that's what that first parameter is)

it would be nice if maybe libopenbsd-compat's getaddrinfo copied ai_family,
ai_socktype and ai_protocol to the returned struct addrinfo's. yes, i admit, we
need to upgrade



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.