Messages in this thread | | | Date | Wed, 3 Dec 2014 01:47:13 +1100 | Subject | Re: [PATCH 1/2] fs: introduce sendfd() syscall | From | Alex Dubov <> |
| |
> User A can send fd(s) to processes belonging to user B, even if user B > does (probably) not want this to happen ?
1. Process A must have sufficient permissions to signal process B. This will only happen if process A belongs to the same user as process B or has elevated capabilities, which can not appear by themselves (and if root on some machine can not be trusted, then all is lost anyway).
2. If process B has not specified explicitly how it wants the particular signal to be handled, it will be killed by the default handler. End of story, nothing else is going to happen.
I suppose, I can add an extra permissions check prior to creating the new file descriptor in the first place.
> Also, relying on signals seems quite old fashion these days. How about > multi-threaded programs wanting separate channels to receive fds ?
Most multi-threaded programs share the same file table between all threads (unless some fancy clone() magic is involved), so the issue is rather mundane. At any rate, each thread has its own pid and the usual signal routing applies.
At a more generic level Posix real-time signals are anything, but old-fashioned. sigqueue()/signalfd() pair provides a very convenient, low overhead micro-messaging facility with ordered, reliably delivery. I fail to see what's wrong with making a worthy use of it.
| |