NetBSD Problem Report #10666

Received: (qmail 20536 invoked from network); 24 Jul 2000 17:23:28 -0000
Message-Id: <200007241722.TAA12151@idle.trapdoor.vip.at>
Date: Mon, 24 Jul 2000 19:22:53 +0200 (CEST)
From: rh@netbsd.org
Reply-To: rh@netbsd.org
To: gnats-bugs@gnats.netbsd.org
Subject: getaddrinfo(3) fails if called with ai_socktype = ai_protocol = 0
X-Send-Pr-Version: 3.95

>Number:         10666
>Category:       lib
>Synopsis:       roken_getaddrinfo_hostspec() uses getaddrinfo in nonstandard way
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    lib-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Jul 24 17:24:00 +0000 2000
>Closed-Date:    
>Last-Modified:  Tue Apr 14 20:46:17 +0000 2009
>Originator:     Rene Hexel
>Release:        1.5_ALPHA 20000719
>Organization:

>Environment:

System: NetBSD ceti.trapdoor.vip.at 1.5_ALPHA NetBSD 1.5_ALPHA (CETI) #1: Wed Jul 19 12:59:17 CEST 2000 rh@ceti.trapdoor.vip.at:/usr/local/src/sys/src/sys/arch/i386/compile/CETI i386


>Description:
	When called with a zero-filled addrinfo hints structure, getaddrinfo(3)
currently fails with EAI_SERVICE despite the manual page claiming that
ai_socktype and ai_protocol may be zero.  This specific problem causes
kpasswd(8) to fail, because roken_getaddrinfo_hostspec() in
basesrc/crypto/dist/heimdal/lib/roken/getaddrinfo_hostspec.c passes
exactly such a structure when called with the default kerberos5 server
name "kerberos.<mydomain>" (without a leading "tcp/", "udp/", etc. prefix).

>How-To-Repeat:
	Set up kerberos, make sure your krb5.conf does *not* contain an
	"admin_server = foo" line.

	Now try changing any password using "kpasswd" and wonder why you
	always get

	kpasswd: krb5_change_password: Bad file descriptor

	After some investigation, discover that EBADF which causes this
	bogus error message has the same numerical value as EAI_SERVICE
	as returned by getaddrinfo(3).

>Fix:
	Make getaddrinfo(3) treat a zero-filled addrinfo hints structure the
	same way as a NULL addrinfo structure.

	Alternatively (if this is not desired), fix
	roken_getaddrinfo_hostspec() to pass a NULL hints structure instead of
	a zero-filled addrinfo if a given host is not prefixed with a matching
	protocol.

	Workaround: until this is fixed, always specify
	"admin_server = protocol/server.domain" in your /etc/krb5.conf
>Release-Note:
>Audit-Trail:

From: joda@pdc.kth.se (Johan Danielsson)
To: rh@netbsd.org
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: lib/10666: getaddrinfo(3) fails if called with ai_socktype = ai_protocol = 0
Date: 24 Jul 2000 19:40:06 +0200

 rh@netbsd.org writes:

 > When called with a zero-filled addrinfo hints structure,
 > getaddrinfo(3) currently fails with EAI_SERVICE despite the manual
 > page claiming that ai_socktype and ai_protocol may be zero.

 This is a well known bug, but the people that care about this
 interface don't think it's a bug.

 > This specific problem causes kpasswd(8) to fail

 Known problem, will be fixed `soon'. Use the workaround for now.

 /Johan

From: "Dr. Rene Hexel" <rh@vip.at>
To: Johan Danielsson <joda@pdc.kth.se>
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: lib/10666: getaddrinfo(3) fails if called with ai_socktype = 
 ai_protocol = 0
Date: Mon, 24 Jul 2000 20:57:44 +0200

 Johan Danielsson wrote:

 > rh@netbsd.org writes:
 > 
 > > When called with a zero-filled addrinfo hints structure,
 > > getaddrinfo(3) currently fails with EAI_SERVICE despite the manual
 > > page claiming that ai_socktype and ai_protocol may be zero.
 > 
 > This is a well known bug, but the people that care about this
 > interface don't think it's a bug.

   Okay, that's why I included the alternative (fix libroken to pass a
 NULL hints structure instead of a zero-filled one).  However, in this
 case, I believe that at least the manpage for getaddrinfo(3) should be
 updated to reflect that only either ai_socktype or ai_protocol must be
 non-zero (or whatever the real requirements are).

 > > This specific problem causes kpasswd(8) to fail
 > 
 > Known problem, will be fixed `soon'. Use the workaround for now.

   That's fine with me (now that I know there is one, after a couple of
 hours searching for the cause of the problem ;-)

   Cheers
       ,
    Rene

From: itojun@iijlab.net
To: rh@netbsd.org
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: lib/10666: getaddrinfo(3) fails if called with ai_socktype = ai_protocol = 0
Date: Tue, 25 Jul 2000 09:06:48 +0900

 >>Synopsis:       getaddrinfo(3) fails if called with ai_socktype = ai_protocol = 0

 	could you give me more information about what you have passed
 	as the argument?  i guess you passed numeric port number (2nd argument).
 	in that case, we are supposed to return error.  this is not a bug.

 itojun

From: "Dr. Rene Hexel" <rh@vip.at>
To: itojun@iijlab.net
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: lib/10666: getaddrinfo(3) fails if called with ai_socktype = 
 ai_protocol = 0
Date: Tue, 25 Jul 2000 07:12:27 +0200

 itojun@iijlab.net wrote:

 > >>Synopsis:       getaddrinfo(3) fails if called with ai_socktype = ai_protocol = 0
 > 
 >         could you give me more information about what you have passed
 >         as the argument?  i guess you passed numeric port number (2nd argument).
 >         in that case, we are supposed to return error.  this is not a bug.

   This is correct, a numeric port number was indeed passed.  In this
 case, the problem, however, is that not I (personally) called it that
 way, but an in-tree program: kpasswd(8) (via
 libroken/getaddrinfo_hostspec()).  Therefore, this problem should be
 fixed, one way or another.  If getaddrinfo(3) works as expected, then
 getaddrinfo_hostspec() is broken, and the file that should be fixed is
 basesrc/crypto/dist/heimdal/lib/roken/getaddrinfo_hostspec.c (see my
 second "fix" suggestion in the PR).

   Also, I believe that in this case, the manpage for getaddrinfo(3)
 should be updated to make this clear.  At the moment, the relevant part
 reads


                             "In this hints structure all members other
 than
    ai_flags, ai_family, ai_socktype, and ai_protocol must be zero or a
 NULL
    pointer.  A value of PF_UNSPEC for ai_family means the caller will
 accept
    any protocol family.  A value of 0 for ai_socktype means the caller
 will
    accept any socket type.  A value of 0 for ai_protocol means the
 caller
    will accept any protocol."


   Some comment should be added, that this is not valid if a numeric port
 number was passed as second argument.  Otherwise, other people might
 make the same mistake again.

   Cheers
       ,
    Rene

From: itojun@iijlab.net
To: rh@netbsd.org
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: lib/10666: getaddrinfo(3) fails if called with ai_socktype = ai_protocol = 0
Date: Tue, 25 Jul 2000 14:16:11 +0900

 >  This is correct, a numeric port number was indeed passed.  In this
 >case, the problem, however, is that not I (personally) called it that
 >way, but an in-tree program: kpasswd(8) (via
 >libroken/getaddrinfo_hostspec()).  Therefore, this problem should be
 >fixed, one way or another.  If getaddrinfo(3) works as expected, then
 >getaddrinfo_hostspec() is broken, and the file that should be fixed is
 >basesrc/crypto/dist/heimdal/lib/roken/getaddrinfo_hostspec.c (see my
 >second "fix" suggestion in the PR).

 	i've contacted assar for help.

 >  Also, I believe that in this case, the manpage for getaddrinfo(3)
 >should be updated to make this clear.  At the moment, the relevant part
 >reads

 	based on recent PRs regarding to this, I added some more wording on it.
 	(please look at lib/libc/net/getaddrinfo.3 revision 1.15)
 	please let me know if it is still unclear.

 itojun

From: "Dr. Rene Hexel" <rh@vip.at>
To: itojun@iijlab.net
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: lib/10666: getaddrinfo(3) fails if called with ai_socktype = 
 ai_protocol = 0
Date: Tue, 25 Jul 2000 07:34:59 +0200

 itojun@iijlab.net wrote:

 >         i've contacted assar for help.

   Thanks!

 >         based on recent PRs regarding to this, I added some more wording on it.
 >         (please look at lib/libc/net/getaddrinfo.3 revision 1.15)
 >         please let me know if it is still unclear.

   Yes, this makes things a lot clearer, thank you.  I believe we also
 should pull this up into the 1.5 tree as this affects both -current and
 1.5.

   Cheers
       ,
    Rene

Responsible-Changed-From-To: lib-bug-people->assar 
Responsible-Changed-By: itojun 
Responsible-Changed-When: Wed Aug 2 07:25:01 PDT 2000 
Responsible-Changed-Why:  

assar will  revisit it after he fixes it in heimdal tree 

Responsible-Changed-From-To: assar->lha 
Responsible-Changed-By: fair 
Responsible-Changed-When: Tue May 25 00:56:44 UTC 2004 
Responsible-Changed-Why:  

Assar has gone inactive, so this goes to our current Kerberos expert. 

Responsible-Changed-From-To: lha->lib-bug-people
Responsible-Changed-By: spz@NetBSD.org
Responsible-Changed-When: Tue, 14 Apr 2009 20:46:17 +0000
Responsible-Changed-Why:
lha is status observer now and thus can't fix this


>Unformatted:

Home	PR Database Search