linux-kernel - Unexpected behavior: Sending signalfd over AF

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <s7b1qsx3n4t.fsf@dokucode.de>
Date:   Tue, 30 Aug 2022 14:57:06 +0200
From:   Christian Dietrich <christian.dietrich@...h.de>
To:     linux-kernel@...r.kernel.org
Cc:     Max Krüger <maxk@...teo.de>,
        John 'Warthog9' Hawley <warthog9@...lescrag.net>
Subject: Unexpected behavior: Sending signalfd over AF_UNIX

[John is also on Cc: since I sent the mail before, but somehow vger ate
 the mail and it did not arrive on the LKML]

Hi everyone!

For a small pet project of mine[1], I experimented with signalfd and
wanted to send it over UNIX domain sockets. Thereby, I encountered an
unexpected behavior:

My expectation was that task A can create a signalfd and send it to
task B, whereby B becomes able to receive the signals of task A.

However, this is not whats happening there. What is actually happening
is that I can correctly transfer the fd to the other process. But
instead of read(2)-ing the siginfos of task A in task B, I now receive
the signals of task B on this foreign file descriptor.

And by looking at the code, this is also the implemented behavior.
There, the code references `current' at various places and signalfd_ctx
does not hold a `struct task_struct*' but only a signal mask.

As already said, this behavior was unexpected for me. What would be
less surpringing would be one of the following:

A. I cannot transfer the signalfd fd at all (are there non-transferable fds?)

B. I can read the signals of task A in task B

With B, there remains the question, whether I should read those signals
directed to task A or to its task group. If route B is chosen, it would
also be great to derive a signalfd from a pidfd.

And yes, the whole idea of sending my own signalfd to another task is
kind of insane. However, for the sake of orthogonality, this would just
be beautiful and I could point my students to this and say: Look! In
Linux, file descriptors are just capabilities that can be transferred
between processes.

chris

[1] I'm currently working on a system-call Christmas calendar that has
    a nice exercise for every day before Christmas.
-- 
Prof. Dr.-Ing. Christian Dietrich
Operating System Group (E-EXK4)
Technische Universität Hamburg
Am Schwarzenberg-Campus 3 (E), 4.092
21073 Hamburg

eMail:  christian.dietrich@...h.de
Tel:    +49 40 42878 2188
WWW:    https://osg.tuhh.de/