Re: getsockopt(2)

[David Holland <dholland-tech%netbsd.org@localhost>]

On Thu, Dec 07, 2017 at 03:04:32PM +0000, Robert Swindells wrote:
 > I wrote:
 >> Does anyone know why we don't use the input 'optlen' parameter to the
 >> getsockopt(2) syscall, we do write back to it on return.
 >>  [...]
 >> 
 >> There are also lots of places in sctp_usrreq that want to use it.
 >> 
 >> I can set it with the following patch (line numbers will be slightly
 >> out), but wondered if there was a reason for the current behaviour.
 >>  [...]
 > 
 > Has anyone had any other thoughts on this ?
 > 
 > I still think that the one line change shown here is correct, it will 
 > allocate a buffer that gets filled by the stuff to be copied back to
 > userspace.

The man page for getsockopt says that the optlen argument should be
initialized with the size before calling getsockopt:

     The parameters optval and optlen are used to access option values for
     setsockopt().  For getsockopt() they identify a buffer in which the value
     for the requested option(s) are to be returned.  For getsockopt(), optlen
     is a value-result parameter, initially containing the size of the buffer
     pointed to by optval, and modified on return to indicate the actual size
     of the value returned.

This is also the traditional behavior of this type of call (compare
e.g. getpeername) and there's no particular reason getsockopt should
be different.

So I think (a) any code we have that doesn't initialize the value is
wrong and should be fixed; (b) any existing kernel code that blats
values out to the buffer without checking the user's length is wrong
and should be fixed; and (c) if this is an endemic problem we should
fix all the wrong user code and then version the syscall before
changing the kernel to behave as documented. (but hopefully that isn't
necessary)

Am I missing something? I'm not sure how the subsequent discussion
morphed into ways to hack setsockopt to serve as getsockopt...

-- 
David A. Holland
dholland%netbsd.org@localhost