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

Only now get to this...

Op 12-05-2026 15:06 CEST schreef Christian Brauner [off-list ref]:

 
On Wed, Apr 29, 2026 at 07:04:25PM -0700, Kuniyuki Iwashima wrote:

quoted

On Tue, Apr 28, 2026 at 10:51 AM Jori Koolstra [off-list ref] wrote:

quoted

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.

quoted

 - 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;
};

quoted

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.

quoted

quoted

-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 :(