From: Jori Koolstra <jkoolstra@xs4all.nl>
To: Kuniyuki Iwashima <kuniyu@google.com>
Cc: Christian Brauner <brauner@kernel.org>,
Aleksa Sarai <cyphar@cyphar.com>,
"David S . Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Simon Horman <horms@kernel.org>,
netdev@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [net-next v5 1/4] net: af_unix: enable custom setsockopt for all socket types
Date: Sun, 19 Jul 2026 14:31:26 +0200 (CEST) [thread overview]
Message-ID: <2048838556.1496380.1784464286664@kpc.webmail.kpnmail.nl> (raw)
In-Reply-To: <CAAVpQUCD27YphUQ=aL3PyPtWwTo0tEtaFt-hvyoyCnepGAmYCQ@mail.gmail.com>
> Op 14-07-2026 11:19 CEST schreef Kuniyuki Iwashima <kuniyu@google.com>:
>
>
> On Sun, Jul 12, 2026 at 9:29 PM Jori Koolstra <jkoolstra@xs4all.nl> wrote:
> >
> > unix_setsockopt() and the SOCK_CUSTOM_SOCKOPT flag were only wired up
> > for SOCK_STREAM (introduced along with the stream-only SO_INQ).
> > Consequently custom AF_UNIX options are unreachable on SOCK_DGRAM and
> > SOCK_SEQPACKET: those setsockopt() calls bypass unix_setsockopt() and
> > fall through to the generic sock_setsockopt(), failing with
> > -ENOPROTOOPT.
> >
> > Set SOCK_CUSTOM_SOCKOPT for every AF_UNIX socket type in unix_create(), and
> > also for accepted sockets in unix_accept() (reachable for stream and
> > seqpacket).
> >
> > This is a prerequisite for making SO_RIGHTS_NOTRUNC settable on all AF_UNIX
> > socket types.
> >
> > Signed-off-by: Jori Koolstra <jkoolstra@xs4all.nl>
> > ---
> > net/unix/af_unix.c | 10 ++++++----
> > 1 file changed, 6 insertions(+), 4 deletions(-)
> >
> > diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
> > index f7a9d55eee8a..3d256255085b 100644
> > --- a/net/unix/af_unix.c
> > +++ b/net/unix/af_unix.c
> > @@ -949,7 +949,7 @@ static int unix_setsockopt(struct socket *sock, int level, int optname,
> > switch (optname) {
> > case SO_INQ:
> > if (sk->sk_type != SOCK_STREAM)
> > - return -EINVAL;
> > + return -ENOPROTOOPT;
> >
> > if (val > 1 || val < 0)
> > return -EINVAL;
> > @@ -1005,6 +1005,7 @@ static const struct proto_ops unix_dgram_ops = {
> > #endif
> > .listen = sock_no_listen,
> > .shutdown = unix_shutdown,
> > + .setsockopt = unix_setsockopt,
> > .sendmsg = unix_dgram_sendmsg,
> > .read_skb = unix_read_skb,
> > .recvmsg = unix_dgram_recvmsg,
> > @@ -1029,6 +1030,7 @@ static const struct proto_ops unix_seqpacket_ops = {
> > #endif
> > .listen = unix_listen,
> > .shutdown = unix_shutdown,
> > + .setsockopt = unix_setsockopt,
> > .sendmsg = unix_seqpacket_sendmsg,
> > .recvmsg = unix_seqpacket_recvmsg,
> > .mmap = sock_no_mmap,
> > @@ -1142,9 +1144,10 @@ static int unix_create(struct net *net, struct socket *sock, int protocol,
> > if (protocol && protocol != PF_UNIX)
> > return -EPROTONOSUPPORT;
> >
> > + set_bit(SOCK_CUSTOM_SOCKOPT, &sock->flags);
>
> Please move this to unix_create1(), then we don't need the chunk below.
>
>
I don't understand how this helps. The accept() path gets its struct socket from
sock_alloc() not via unix_create() afaict. Also, unix_create1() is called with
sock == NULL on connect(), so now you have to guard against that too.
But maybe I misunderstand you?
I do agree with you other comment, accept() should probably inherit the truncate
behavior from the listen() socket.
Thanks,
Jori.
next prev parent reply other threads:[~2026-07-19 12:31 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-12 19:29 [net-next v5 0/4] net: af_unix: useful handling of LSM denials on SCM_RIGHTS Jori Koolstra
2026-07-12 19:29 ` [net-next v5 1/4] net: af_unix: enable custom setsockopt for all socket types Jori Koolstra
2026-07-14 9:19 ` Kuniyuki Iwashima
2026-07-19 12:31 ` Jori Koolstra [this message]
2026-07-28 14:05 ` Jori Koolstra
2026-07-30 18:41 ` Kuniyuki Iwashima
2026-07-12 19:29 ` [net-next v5 2/4] net: scm: move scm_detach_fds() from common path to scm_recv_unix() Jori Koolstra
2026-07-12 19:29 ` [net-next v5 3/4] net: af_unix: useful handling of LSM denials on SCM_RIGHTS Jori Koolstra
2026-07-14 9:22 ` Kuniyuki Iwashima
2026-07-12 19:29 ` [net-next v5 4/4] selftest: Add tests for " Jori Koolstra
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=2048838556.1496380.1784464286664@kpc.webmail.kpnmail.nl \
--to=jkoolstra@xs4all.nl \
--cc=brauner@kernel.org \
--cc=cyphar@cyphar.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=kuniyu@google.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
/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