Subject: Re: iruserok() with address-family independence

From: Jean-Luc Richier <[email-masked]>
Date: Fri, 14 Jan 2000 11:52:52 +0100 (MET)

Dans votre courrier du 14 Jan 16:38 vous ecrivez :
>
>>	In looking at the manpages from several standards based UNIX
>>systems I see no reference to iruserok.  I also can't find prototypes
>>for these functions in any header files on these standards based UNIX
>>systems.  I take this to mean that they are not part of any UNIX standard.
>>	My personal opinion is that 2292bis does not need to make any
>>statement about these functions since they are not part of any standard
>>or defacto standard API.  As long as an implementation's ruserok works
>>as expected for IPv4 and IPv6 I don't think anything more needs to be defined
>>regarding what happens behinds the scenes.
>
>	Hmm, I see.  so all I'll need to do is to get some agreement
>	about iruserok_sa or ruserok_sa (because they are publically available
>	function and used in BSD/linux rshd/rlogind, we need to have certain
>	agreement).  I still vote for iruserok_sa, and not ruserok_sa,
>	for minimum surprise in existing code.
>
>
>	Another one we have on the table is bindresvport() (NOTE: old one, like
>		int bindresvport(int sd, struct sockaddr_in *sin)
>
>	I'm in favor of bindresvport_af(), with additional "af" argument.
>	I don't want too many changes in behavior and would like to keep
>	the change minimum.
>		int bindresvport_af(int sd, struct sockaddr *sa, int af)
>	(openbsd-current already has this)
>
>	I vote against
>		int bindresvport_sa(int sd, struct sockaddr *sa)
>	(which takes "af" from sa->sa_family).   bindresvport() allows 
>	"sin" to be NULL so we always need to pass address family even in
>	this case.  I do not want behavior change here.

I do not agree, bindresvport_sa does not take  "af" from sa->sa_family,
it already know the family from the socket argument sd. So even it sa is
NULL, bindresvport - or bindresvport_sa still works. For exemple do a
getsockname of sd to find the family.

So I think an af argument is redundant. 
I fact in an early port of libc I tried it, and in some INET/INET6
independant code I had to add code to compute the af argument simply to
pass it. Letting bindresvport* to compute it is simpler.

I vote for bindresvport_sa, (or keeping bindresvport).

According to my experience, the problems with bindresvport are:
- the sa_family field of sa (everybody initializes it to AF_INET)
   In INRIA port I added the AF_UNSPEC value to signify : unknown, set it.
- and over all the size of the returned value -with a PF_INET6 sd, the
  returned sockaddr_in6 will overflow a sockaddr_in buffer.
  That is why we may need a new function for forcing arg checks, with or
  without a len argument (len of sa argument). I do not think len is needed,
  if the new function use a generic type (sockaddr) for sa or a big type
  (sockaddr_storage).

-- 
Jean-Luc RICHIER ([email-masked]  [email-masked])
Laboratoire Logiciels, Systemes et Reseaux (LSR-IMAG)
IMAG-CAMPUS, BP 72, F-38402 St Martin d'Heres Cedex
Tel : +33 4 76 82 72 32 Fax : +33 4 76 82 72 87
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Fri, 14 Jan 2000 02:59:40 -0800

>getsockname of sd to find the family.

	Could you tell me more about your behavior in sa == NULL case?

	Also, please do not assume IPv4 mapped address for discussion,
	there are systems which does not (and will not) have it.  AF_INET6
	socket does not grab IPv4 connections, so you need to be explicit
	about address family, or use getaddrinfo to make a loop.

>  if the new function use a generic type (sockaddr) for sa or a big type

	How did you made sure that there's no buffer overrun?
	In your method third-party code would not notice the change and there
	will be buffer overrun if you regard AF_UNSPEC as AF_INET6
	(or you will end up hardcode AF_UNSPEC behavior to AF_INET).

itojun

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Fri, 14 Jan 2000 03:02:48 -0800

>	How did you made sure that there's no buffer overrun?

	I may not be clear enough,
	I understand there are options in avoiding buffer overrun,
	I would like to know how you did it in your previous implementation,
	without having len, nor without changing function signature (to
	sockaddr_storage * - I don't really like passing around
	sockaddr_storage *).

itojun