Re: [PATCH v2] signal: add procfd_signal() syscall
From: Aleksa Sarai
Date: Tue Dec 04 2018 - 01:04:14 EST
On 2018-12-03, Christian Brauner <christian@xxxxxxxxxx> wrote:
> > > As I pointed out in another mail my I is to make this work by using
> > > file descriptors for /proc/<pid>/task/<tid>. I don't want this in the
> > > initial patchset though. I prefer to slowly add those features once
> > > we have gotten the basic functionality in.
> >
> > Do you want to land all this in one kernel release? I wonder how
> > applications are supposed to discover kernel support if functionality is
> > split across several kernel releases. If you get EINVAL or EBADF, it
> > may not be obvious what is going on.
>
> Sigh, I get that but I really don't want to have to land this in one big
> chunk. I want this syscall to go in in a as soon as we can to fulfill
> the most basic need: having a way that guarantees us that we signal the
> process that we intended to signal.
>
> The thread case is easy to implement on top of it. But I suspect we will
> quibble about the exact semantics for a long time. Even now we have been
> on multiple - justified - detrous. That's all pefectly fine and
> expected. But if we have the basic functionality in we have time to do
> all of that. We might even land it in the same kernel release still. I
> really don't want to come of as tea-party-kernel-conservative here but I
> have time-and-time again seen that making something fancy and cover ever
> interesting feature in one patchset takes a very very long time.
>
> If you care about userspace being able to detect that case I can return
> EOPNOTSUPP when a tid descriptor is passed.
Personally, I'm +1 on -EOPNOTSUPP so we can get an MVP merged, and add
new features in later patches.
> > What happens if you use the new interface with an O_PATH descriptor?
>
> You get EINVAL. When an O_PATH file descriptor is created the kernel
> will set file->f_op = &empty_fops at which point the check I added
> if (!proc_is_tgid_procfd(f.file))
> goto err;
> will fail. Imho this is correct behavior since technically signaling a
> struct pid is the equivalent of writing to a file and hence doesn't
> purely operate on the file descriptor level.
Not to mention that O_PATH file descriptors are a whole kettle of fish
when it comes to permission checking semantics.
--
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>
Attachment:
signature.asc
Description: PGP signature