From: David Laight <David.Laight@ACULAB.COM>
To: 'Paul Moore' <paul@paul-moore.com>
Cc: Alexei Starovoitov <alexei.starovoitov@gmail.com>,
Martin KaFai Lau <martin.lau@kernel.org>,
Alexei Starovoitov <ast@kernel.org>,
"Network Development" <netdev@vger.kernel.org>,
LSM List <linux-security-module@vger.kernel.org>,
"selinux@vger.kernel.org" <selinux@vger.kernel.org>
Subject: RE: SO_PEERSEC protections in sk_getsockopt()?
Date: Mon, 10 Oct 2022 15:34:24 +0000 [thread overview]
Message-ID: <ffe2b21ce6e04b07891261641b4d1f5b@AcuMS.aculab.com> (raw)
In-Reply-To: <CAHC9VhQRywim8vKGUM+=US0nq_fqZH7MShaV2tC14gw5xUrSDA@mail.gmail.com>
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)
next prev parent reply other threads:[~2022-10-10 15:34 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-05 20:44 SO_PEERSEC protections in sk_getsockopt()? Paul Moore
2022-10-07 17:43 ` Paul Moore
2022-10-07 19:12 ` Alexei Starovoitov
2022-10-07 20:06 ` Paul Moore
2022-10-07 21:55 ` Alexei Starovoitov
2022-10-09 22:01 ` Paul Moore
2022-10-10 6:19 ` Alexei Starovoitov
2022-10-10 13:28 ` Paul Moore
2022-10-10 14:10 ` Alexei Starovoitov
2022-10-10 15:50 ` Paul Moore
2022-10-10 12:54 ` David Laight
2022-10-10 13:19 ` Paul Moore
2022-10-10 15:34 ` David Laight [this message]
2022-10-10 15:56 ` Paul Moore
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ffe2b21ce6e04b07891261641b4d1f5b@AcuMS.aculab.com \
--to=david.laight@aculab.com \
--cc=alexei.starovoitov@gmail.com \
--cc=ast@kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=martin.lau@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=paul@paul-moore.com \
--cc=selinux@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox