Re: Minimal effort/low overhead file descriptor duplication over Posix.1b s

From: Jonathan Corbet
Date: Tue Dec 02 2014 - 10:26:50 EST

On Tue, 2 Dec 2014 15:35:17 +1100
Alex Dubov <alex.dubov@xxxxxxxxx> wrote:

> int sendfd(pid_t pid, int sig, int fd)
> Given a target process pid, the sendfd() syscall will create a duplicate
> file descriptor in a target task's (referred by pid) file table pointing to
> the file references by descriptor fd. Then, it will attempt to notify the
> target task by issuing a Posix.1b real-time signal (sig), carrying the new
> file descriptor as integer payload. If real-time signal can not be enqueued
> at the destination signal queue, the newly created file descriptor will be
> promptly closed.

[ CC += linux-api ]

So I'm not a syscall API design expert, but this one raises a few
questions with me.

- Messing with another process's file descriptor table without its
knowledge looks like a possible source of all kinds problems. Might
there be race conditions with close()/dup() code, for example? And
remember that users can be root in a user namespace; maybe there's no
potential for mischief there, but it needs to be considered.

- Forcing the use of realtime signals seems strange; this isn't a
realtime operation by any stretch.

- How might the sending process communicate to the recipient what the fd
is for? Even if a process only expects one type of file descriptor,
the ability to communicate information other than its number seems
like it would often be useful.

Some of these concerns might be addressable by requiring the recipient to
call acceptfd() (or some such) with the ability to use poll(). As an
alternative, I believe kdbus has fd-passing abilities; if kdbus goes in,
would you still need this feature?


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at