From: Kuniyuki Iwashima <kuniyu@amazon.com>
To: <willemdebruijn.kernel@gmail.com>
Cc: <brauner@kernel.org>, <davem@davemloft.net>,
<edumazet@google.com>, <horms@kernel.org>, <kuba@kernel.org>,
<kuni1840@gmail.com>, <kuniyu@amazon.com>,
<netdev@vger.kernel.org>, <pabeni@redhat.com>,
<willemb@google.com>
Subject: Re: [PATCH v2 net-next 7/9] af_unix: Inherit sk_flags at connect().
Date: Mon, 12 May 2025 15:34:55 -0700 [thread overview]
Message-ID: <20250512223729.58686-1-kuniyu@amazon.com> (raw)
In-Reply-To: <68224e25b13ac_eb9592943d@willemb.c.googlers.com.notmuch>
From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Date: Mon, 12 May 2025 15:38:13 -0400
> Kuniyuki Iwashima wrote:
> > For SOCK_STREAM embryo sockets, the SO_PASS{CRED,PIDFD,SEC} options
> > are inherited from the parent listen()ing socket.
> >
> > Currently, this inheritance happens at accept(), because these
> > attributes were stored in sk->sk_socket->flags and the struct socket
> > is not allocated until accept().
> >
> > This leads to unintentional behaviour.
> >
> > When a peer sends data to an embryo socket in the accept() queue,
> > unix_maybe_add_creds() embeds credentials into the skb, even if
> > neither the peer nor the listener has enabled these options.
> >
> > If the option is enabled, the embryo socket receives the ancillary
> > data after accept(). If not, the data is silently discarded.
> >
> > This conservative approach works for SO_PASS{CRED,PIDFD,SEC}, but not
> > for SO_PASSRIGHTS; once an SCM_RIGHTS with a hung file descriptor is
> > sent, it’s game over.
>
> Should this be a fix to net then?
Regarding SO_PASS{CRED,PIDFD,SEC}, this patch is a small optimisation
to save unnecessary get_pid() etc, like 16e572626961
And, SO_PASSRIGHTS is not yet added here, so this is not a fix.
Maybe I should have clarified like "this works but would not for SO_PASSRIGHTS".
>
> It depends on the move of this one bit from socket to sock. So is not
> a stand-alone patch. But does not need all of the previous cleanup
> patches if needs to be backportable.
>
> >
> > To avoid this, we will need to preserve SOCK_PASSRIGHTS even on embryo
> > sockets.
> >
> > A recent change made it possible to access the parent's flags in
> > sendmsg() via unix_sk(other)->listener->sk->sk_socket->flags, but
> > this introduces an unnecessary condition that is irrelevant for
> > most sockets, accept()ed sockets and clients.
>
> What is this condition and how is it irrelevant? A constraint on the
> kernel having the recent change? I.e., not backportable?
Commit aed6ecef55d7 ("af_unix: Save listener for embryo socket.") is
added for a new GC but is a standalone patch.
If we want to use the listener's flags, the condition will be like...
if (UNIXCB(skb).fp &&
((other->sk_socket && other->sk_socket->sk_flags & SOCK_PASSRIGHTS) ||
(!other->sk_socket && unix_sk(other)->listener->sk->sk_socket->sk_flags && SOCK_PASSRIGHTS)))
next prev parent reply other threads:[~2025-05-12 22:37 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-10 1:56 [PATCH v2 net-next 0/9] af_unix: Introduce SO_PASSRIGHTS Kuniyuki Iwashima
2025-05-10 1:56 ` [PATCH v2 net-next 1/9] af_unix: Factorise test_bit() for SOCK_PASSCRED and SOCK_PASSPIDFD Kuniyuki Iwashima
2025-05-10 1:56 ` [PATCH v2 net-next 2/9] af_unix: Don't pass struct socket to maybe_add_creds() Kuniyuki Iwashima
2025-05-10 1:56 ` [PATCH v2 net-next 3/9] scm: Move scm_recv() from scm.h to scm.c Kuniyuki Iwashima
2025-05-10 1:56 ` [PATCH v2 net-next 4/9] tcp: Restrict SO_TXREHASH to TCP socket Kuniyuki Iwashima
2025-05-12 19:18 ` Willem de Bruijn
2025-05-12 22:14 ` Kuniyuki Iwashima
2025-05-13 2:42 ` Willem de Bruijn
2025-05-13 3:11 ` Kuniyuki Iwashima
2025-05-10 1:56 ` [PATCH v2 net-next 5/9] net: Restrict SO_PASS{CRED,PIDFD,SEC} to AF_{UNIX,NETLINK,BLUETOOTH} Kuniyuki Iwashima
2025-05-10 1:56 ` [PATCH v2 net-next 6/9] af_unix: Move SOCK_PASS{CRED,PIDFD,SEC} to struct sock Kuniyuki Iwashima
2025-05-12 19:20 ` Willem de Bruijn
2025-05-12 22:20 ` Kuniyuki Iwashima
2025-05-13 2:44 ` Willem de Bruijn
2025-05-13 3:18 ` Kuniyuki Iwashima
2025-05-13 2:03 ` kernel test robot
2025-05-10 1:56 ` [PATCH v2 net-next 7/9] af_unix: Inherit sk_flags at connect() Kuniyuki Iwashima
2025-05-12 19:38 ` Willem de Bruijn
2025-05-12 22:34 ` Kuniyuki Iwashima [this message]
2025-05-13 2:48 ` Willem de Bruijn
2025-05-13 3:20 ` Kuniyuki Iwashima
2025-05-10 1:56 ` [PATCH v2 net-next 8/9] af_unix: Introduce SO_PASSRIGHTS Kuniyuki Iwashima
2025-05-10 1:56 ` [PATCH v2 net-next 9/9] selftest: af_unix: Test SO_PASSRIGHTS Kuniyuki Iwashima
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=20250512223729.58686-1-kuniyu@amazon.com \
--to=kuniyu@amazon.com \
--cc=brauner@kernel.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=kuni1840@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=willemb@google.com \
--cc=willemdebruijn.kernel@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.