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

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

Dans votre courrier du 14 Jan  3:02 vous ecrivez :
>
>>>- 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).
>>	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
I avoid overflow simply by using the fd family and the way old programs are
coded:
The only problem is when sa is not null. It should point to a buffer as least
as long as a sockaddr_in.
- With an old program and INET socket no overflow will occur.
- With an old program incompletly ported, the risk is: a socket converted
  to PF_INET6 but a pointer to sockaddr_in. In that case old code asks for
  an explicit setting of sa_family to AF_INET. In that case bind will fail
  (family mismatch) and no value will be returned, so no overflow.
- With an old program correctly ported, the mandatory changes are: 
  changing the socket family to PF_INET6, and setting new value in
  sa_family to a value different that the old one AF_INET. If somebody
  make this change, I do hope that he will also check the type and size of
  the variable. If somebody write `sin.sin_family = AF_INET6;' he should
  know that he is looking for trouble.

  The only thing I added to this is saying that there is a unspecfied family,
  AF_INET or AF_INET6. In that case I can say that such an argument should
  always be a sockaddr_in6 or sockaddr_storage.

Richier

-- 
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]
--------------------------------------------------------------------