SO_PEERSEC protections in sk_getsockopt()?

[David Laight]

From: Paul Moore
> Sent: 10 October 2022 14:19
....
> > It isn't really ideal for the buffer pointer either.
> > That started as a single field (assuming the caller
> > has verified the user/kernel status), then the is_kernel
> > field was added for architectures where user/kernel
> > addresses use the same values.
> > Then a horrid bug (forgotten where) forced the is_kernel
> > field be used everywhere.
> > Again a structure with two pointers would be much safer.
> 
> Any chance you have plans to work on this David?

I'd only spend any significant time on it if there
is a reasonable chance of the patches being accepted.

My use would be an out-of-tree non-GPL module calling
kernel_getsockopt().
The main in-tree user is bpf - which seems to need an
ever-increasing number of socket options, but support has
been added one by one.

While most getsockopt() calls just return set values, SCTP
uses some to retrieve the result of values negotiated with
the peer. The number of valid data streams is needed for
even trivial SCTP applications.
However I've a workaround for a bug in 5.1 to 5.8 that
returned the wrong values (my tests didn't check negotiation)
that also obtains the values on later kernels.
So I'm not (yet) in a hurry!

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)