On Fri 2014-12-05 13:22:50, One Thousand Gnomes wrote:
>
> > 2.a. If task A has sufficient capabilities to send signals to task B, then
> > task A is already in position to do anything it wants with task B, including
> > killing it outright.
>
> Not entirely true.
>
> - We have securirty models
On Sat, Dec 6, 2014 at 12:22 AM, One Thousand Gnomes
wrote:
>
>> 2.a. If task A has sufficient capabilities to send signals to task B, then
>> task A is already in position to do anything it wants with task B, including
>> killing it outright.
>
> Not entirely true.
>
> - We have securirty models
On Sat, Dec 6, 2014 at 6:23 AM, Bastien ROUCARIES
wrote:
>
>
> See senfd recvfd in gnulib. It wirk even under solaris
>
What's so special about a thin wrapper around domain sockets/named
fifos (solaris style)?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
> 2.a. If task A has sufficient capabilities to send signals to task B, then
> task A is already in position to do anything it wants with task B, including
> killing it outright.
Not entirely true.
- We have securirty models like SELinux
- We have namespaces and being able to send an fd between
I would like to present my second attempt at file descriptor duplication over
Posix.1b real-time signal transport. All the constructive points raised
in the previous discussion are believed to be addressed.
To this end, I would like to address some concerns raised in the preceding
discussion:
1.
Present patch introduces exceptionally easy to use, low latency and low
overhead mechanism for transferring file descriptors between cooperating
processes:
int sendfd(pid_t pid, int sig, int fd)
Given a target process pid, the sendfd() will queue a real-time signal for
delivery to task refere
6 matches
Mail list logo
