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

[Jori Koolstra]

Only now get to this...

> Op 12-05-2026 15:06 CEST schreef Christian Brauner <brauner@xxxxxxxxxx>:
> 
>  
> On Wed, Apr 29, 2026 at 07:04:25PM -0700, Kuniyuki Iwashima wrote:
> > On Tue, Apr 28, 2026 at 10:51 AM Jori Koolstra <jkoolstra@xxxxxxxxx> 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.
> > 
> > 
> > >  - 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 ?).
> 
> The socket option suggested later: Wouldn't it be simpler to just add a
> socket that instructs the scm layer to send all fds that were denied
> with a -EPERM sentinel. Then systemd can:
> 
> * detect all fds that were denied simply by seeing they were -EPERM
> * keep the count in tact
> 
> and - see below - get rid of the blatant layering violation in here...

With "add a socket" you mean add a socket option that can be used in the scm layer?
I.e. do something in unix_setsockopt() and define it in unix_custom_sockopt()? Then
we can have an option like

struct unix_sock {
    ...
    unsigned char   whatever_scm_opt:1;
};


> 
> > Then, it will find the -EPERM entry.
> 
> I assume we're talking about the same thing. All the complicated rest
> should be dropped. There's a bunch of nonsense in that uapi entry -
> quite a few items are merely drafts.
> 

We should update them or flag them as "needs further refinement." Is this
stuff that would be interesting to discuss at All Systems Go? I would like
to go, but I'm also already planning to go to Recipes, OSS Korea (if I can
get funding for my talk), and Prague in October.

> > > -int receive_fd(struct file *file, int __user *ufd, unsigned int o_flags)
> > > +int receive_fd_msg(struct file *file, int __user *ufd, unsigned int o_flags,
> > > +              unsigned int *msg_flags)
> > >  {
> > >         int error;
> > >
> > >         error = security_file_receive(file);
> > > -       if (error)
> > > +       if (error) {
> > > +               if (msg_flags)
> > > +                       *msg_flags |= MSG_RIGHTS_DENIAL;
> > > +
> > > +               if (ufd)
> > > +                       put_user(-EPERM, ufd);
> > > +
> > >                 return error;
> > > +       }
> 
> I don't like this. It's bad enought that the generic file layer needs to
> call into __receive_sock() I don't want it to poke into other subsystems
> internals even more. That's just not appropriate. Get this out of the
> VFS's way, please.

Don't know what I was thinking here honestly. This is bad code :(