Re: [PATCH v2] signal: add procfd_signal() syscall

[Christian Brauner]

On December 7, 2018 7:56:44 AM GMT+13:00, Florian Weimer <fweimer@xxxxxxxxxx> wrote:
>* Andy Lutomirski:
>
>>> I suppose that's fine.  Or alternatively, when thread group support
>is
>>> added, introduce a flag that applications have to use to enable it,
>so
>>> that they can probe for support by checking support for the flag.
>>>
>>> I wouldn't be opposed to a new system call like this either:
>>>
>>>  int procfd_open (pid_t thread_group, pid_t thread_id, unsigned
>flags);
>>>
>>> But I think this is frowned upon on the kernel side.
>>
>> I have no problem with it, except that I think it shouldnât return an
>> fd that can be used for proc filesystem access.
>
>Oh no, my intention was that it would just be used with  *_send_signal
>and related functions.

Let's postpone that discussion a little.
I think we don't need a syscall to base this off of pids.
As I said I rather send my revived version of CLONE_NEWFD that would serve the same task.
The same way we could also just add a new open() flag that blocks fs access completely.
I just pitched that idea to Serge a few days back: O_NOCHDIR or similar.
That could even be part of Aleksa's path resolution patchset.

>
>Thanks,
>Florian