From: Jori Koolstra <jkoolstra@xs4all.nl>
To: Kuniyuki Iwashima <kuniyu@google.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>,
Christian Brauner <brauner@kernel.org>, Jan Kara <jack@suse.cz>,
Eric Dumazet <edumazet@google.com>,
Paolo Abeni <pabeni@redhat.com>,
Willem de Bruijn <willemb@google.com>,
"David S . Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>, Jens Axboe <axboe@kernel.dk>,
Kees Cook <kees@kernel.org>, Simon Horman <horms@kernel.org>,
Andy Lutomirski <luto@amacapital.net>,
Will Drewry <wad@chromium.org>, Jeff Layton <jlayton@kernel.org>,
Oleg Nesterov <oleg@redhat.com>, Andrei Vagin <avagin@gmail.com>,
Pavel Tikhomirov <ptikhomirov@virtuozzo.com>,
Mateusz Guzik <mjguzik@gmail.com>,
Joel Granados <joel.granados@kernel.org>,
Charlie Mirabile <cmirabil@redhat.com>,
Aleksa Sarai <cyphar@cyphar.com>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org, io-uring@vger.kernel.org
Subject: Re: [RFC PATCH 1/2] net: af_unix: Useful handling of LSM denials on SCM_RIGHTS
Date: Fri, 1 May 2026 17:34:40 +0200 (CEST) [thread overview]
Message-ID: <89346381.2074764.1777649680664@kpc.webmail.kpnmail.nl> (raw)
In-Reply-To: <CAAVpQUBKeN2KtRkRAFr8sYJM1_-rbkdjsujau5fAyaiP_dO6FA@mail.gmail.com>
> Op 30-04-2026 04:04 CEST schreef Kuniyuki Iwashima <kuniyu@google.com>:
>
>
> On Tue, Apr 28, 2026 at 10:51 AM Jori Koolstra <jkoolstra@xs4all.nl> wrote:
> >
> > Right now if some LSM such as Smack denies an AF_UNIX socket peer to
> > receive an SCM_RIGHTS fd the SCM_RIGHTS fd array will be cut short at
> > that point, and MSG_CTRUNC is set on return of recvmsg(). This is
> > highly problematic behaviour, because it leaves the receiver
> > wondering what happened. As per man page MSG_CTRUNC is supposed to
> > indicate that the control buffer was sized too short, but suddenly
> > a permission error might result in the exact same flag being set.
> > Moreover, the receiver has no chance to determine how many fds got
> > originally sent and how many were suppressed.[1]
> >
> > Add two MSG_* flags:
>
> Since we only have 5 bits remaining for future extension,
> we need to consider the use case a bit more carefully.
>
Right. Since it wasn't a lot of work I implemented it exactly as the request
was made from userspace, and then discuss it from there. By the way, I suppose
nothing can be done about that small flag space?
>
> > - MSG_RIGHTS_DENIAL is set whenever any file is rejected by the LSM
> > during recvmsg() of SCM_RIGHTS fds.
>
> Is this really needed ?
>
> Even if the fd array is truncated, the application will traverse
> the array anyway since it has some fds already installed (to
> clean up in case of MSG_CTRUNC ?).
>
> Then, it will find the -EPERM entry.
>
> I assume no one uses MSG_RIGHTS_DENIAL without
> MSG_RIGHTS_FILTER.
>
I guess that is a fair assumption to make. We can certainly do without
MSG_RIGHTS_DENIAL if saving flags is important. I also suggested that
we may see whether we can make MSG_RIGHTS_FILTER the default behavior.
In the mean time I've found grep.app, and it turns out the answer is no.
Apparently almost no one checks even for the truncation flag (mostly 1 fd
is passed and then it is check the cmsg lenght). But cpython has this for
instance:
/* Close all descriptors coming from SCM_RIGHTS, so they don't leak. */
for (cmsgh = ((msg.msg_controllen > 0) ? CMSG_FIRSTHDR(&msg) : NULL);
cmsgh != NULL; cmsgh = CMSG_NXTHDR(&msg, cmsgh)) {
cmsg_status = get_cmsg_data_len(&msg, cmsgh, &cmsgdatalen);
if (cmsg_status < 0)
break;
if (cmsgh->cmsg_level == SOL_SOCKET &&
cmsgh->cmsg_type == SCM_RIGHTS) {
size_t numfds;
int *fdp;
numfds = cmsgdatalen / sizeof(int);
fdp = (int *)CMSG_DATA(cmsgh);
while (numfds-- > 0)
close(*fdp++);
}
if (cmsg_status != 0)
break;
}
>
> > - If MSG_RIGHTS_FILTER is passed as a flag to recvmsg(), the SCM_RIGHTS
>
> Does this flag need per-recvmsg() granularity ?
>
Perhaps not. What would be the alternative? A fcntl option for the socket fd?
> If the application does not welcome the truncated fd array,
> it would have passed MSG_RIGHTS_FILTER to every
> recvmsg(), no ?
>
Correct.
Thanks,
Jori.
next prev parent reply other threads:[~2026-05-01 15:35 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-28 17:51 [RFC PATCH 0/2] net: af_unix: Useful handling of LSM denials on SCM_RIGHTS Jori Koolstra
2026-04-28 17:51 ` [RFC PATCH 1/2] " Jori Koolstra
2026-04-30 2:04 ` Kuniyuki Iwashima
2026-05-01 15:34 ` Jori Koolstra [this message]
2026-05-02 1:24 ` Kuniyuki Iwashima
2026-05-04 17:43 ` Jori Koolstra
2026-04-28 17:51 ` [RFC PATCH 2/2] selftest: Add tests for useful " 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=89346381.2074764.1777649680664@kpc.webmail.kpnmail.nl \
--to=jkoolstra@xs4all.nl \
--cc=avagin@gmail.com \
--cc=axboe@kernel.dk \
--cc=brauner@kernel.org \
--cc=cmirabil@redhat.com \
--cc=cyphar@cyphar.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=io-uring@vger.kernel.org \
--cc=jack@suse.cz \
--cc=jlayton@kernel.org \
--cc=joel.granados@kernel.org \
--cc=kees@kernel.org \
--cc=kuba@kernel.org \
--cc=kuniyu@google.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=mjguzik@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=oleg@redhat.com \
--cc=pabeni@redhat.com \
--cc=ptikhomirov@virtuozzo.com \
--cc=viro@zeniv.linux.org.uk \
--cc=wad@chromium.org \
--cc=willemb@google.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