Re: Bug with fcntl(n, F_SETOWN, getpid) with NPTL 0.34

David Holmes wrote:
> Looking into the bowels of sock.c sock_no_fcntl does this:
>    case F_SETOWN:
> 	if (current->pgrp != -arg &&
>             current->pid != arg &&
> 	    !capable(CAP_KILL)) return(-EPERM);
> 
> Running as root provides the CAP_KILL capability and the test passes. So
> it seems that there is a discrepancy between the value returned by
> getpid() and the value used internally (current->pid).

getpid() does not return current->pid; it returns current->tgid.
That's a confusing historical artefact.

It is incorrect for a program to use the value of getpid() as the
argument to F_SETOWN.  It should be using the value returned from the
gettid() system call (tid (current->pid) != pid (current-tgid)).  (Yes
the naming is very confusing).  Unfortunately this is not made easy
(gettid() is not a libc function), and the man page is no longer
correct when it says process id.

It would make a lot of sense for the kernel to automatically set the
owner to current->pid when F_SETSIG is called (F_SETOWN is quite
redundant), but at the moment it doesn't do that.

> This only fails with NPTL. If I use LD_ASSUME_KERNEL the test passes 
> threaded and non-threaded.

It is because in the new threading model there is no longer a 1:1
correspondence between pids and threads.  You'll probably find the
program fails under NGPT too.

-- Jamie