Re: Getting PID of socket client

On Sun, Jul 09, 2017 at 05:43:22PM +0100, David Chisnall wrote:
> On 9 Jul 2017, at 14:25, Stefan Ehmann <shoesoft_at_gmx.net> wrote:

> > Don't why the structs are not compatible, maybe because:
> > "The process ID cmcred_pid should not be looked up (such as via the
> > KERN_PROC_PID sysctl) for making security decisions.  The sending
> > process could have exited and its process ID already been reused for
> > a new process."

> Note that having the kernel provide a process descriptor instead of a
> PID would allow the userspace process to have race-free access to the
> PID.

This is an interesting idea, but would require quite a few changes.

First, current process descriptors act as an artificial parent process,
suppressing the normal SIGCHLD to the parent and not being matched by a
wildcard waitpid() or similar function. A new kind of process descriptor
would have to be added which leaves this behaviour unchanged and could
exist in parallel with a process descriptor from pdfork().

Second, pdgetpid() makes no guarantees whether the process ID still
exists. It should not make them either for this case, since this would
allow another user to hold onto process slots for RLIMIT_NPROC. The only
solution would be to add variants of the necessary calls that take a
process descriptor instead of a process ID.

-- 
Jilles Tjoelker