Re: [RFC PATCH 1/2] net: af_unix: Useful handling of LSM denials on SCM_RIGHTS

[Kuniyuki Iwashima <kuniyu@google.com>]

On Fri, May 1, 2026 at 8:34 AM Jori Koolstra <jkoolstra@xs4all.nl> wrote:
>
>
> > 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?

We could reuse an existing flag (e.g. MSG_FIN, MSG_RST)
if we were confident enough that the userspace does not use
the flag for a specific socket type.

Another option is to add another syscall, recvmsg2.


>
> >
> > >  - 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?

I'd add a new socket option like

setsockopt(SOL_SOCKET, SO_RIGHTS_TRUNC, &(int){0}, sizeof(int));


>
> > If the application does not welcome the truncated fd array,
> > it would have passed MSG_RIGHTS_FILTER to every
> > recvmsg(), no ?
> >
>
> Correct.
>
>
> Thanks,
> Jori.