Most recent kernel where this bug did not occur: 2.6.22 Distribution: Kubuntu Hardware Environment: VMWare workstation 6 Software Environment: Problem Description: calling fcntl with F_GETOWN on a socket gives allways zero instead of the PID of the socket. The fcntl code is right but the data is zero in the struct file element. It sounds like pid is not set when the socket is attached to the fd in sock_attach_fd() of net/socket.c. I would add something like this: file->f_owner.pid=find_get_pid(task->pid); file->f_owner.pid_type=PIDTYPE_PID; in sock_attach_fd() of net/socket.c Steps to reproduce: s=socket(...); pid=fcntl(s, F_GETOWN);
Reply-To: akpm@linux-foundation.org (please respond via emailed reply-to-all, not vie the bugzilla web interface) On Mon, 8 Oct 2007 09:18:02 -0700 (PDT) bugme-daemon@bugzilla.kernel.org wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=9132 > > Summary: fcntl GET_OWN reports 0 for sockets instead of PID > Product: Networking > Version: 2.5 > KernelVersion: 2.6.22 > Platform: All > OS/Version: Linux > Tree: Mainline > Status: NEW > Severity: normal > Priority: P1 > Component: Other > AssignedTo: acme@ghostprotocols.net > ReportedBy: ff@ozog.com > > > Most recent kernel where this bug did not occur: 2.6.22 > Distribution: Kubuntu > Hardware Environment: VMWare workstation 6 > Software Environment: > Problem Description: calling fcntl with F_GETOWN on a socket gives allways > zero > instead of the PID of the socket. The fcntl code is right but the data is > zero > in the struct file element. It sounds like pid is not set when the socket is > attached to the fd in sock_attach_fd() of net/socket.c. > > I would add something like this: > > file->f_owner.pid=find_get_pid(task->pid); > file->f_owner.pid_type=PIDTYPE_PID; > > in sock_attach_fd() of net/socket.c > > Steps to reproduce: > > s=socket(...); > pid=fcntl(s, F_GETOWN); > You state that the problem is present in 2.6.22 and also did not occur in 2.6.22. I assume it has always been like this.
You are correct, I have tested back to 2.6.18 and the bug is still here. So I don't know when the problem did NOT occur. Fran
If you don't set an owner then of course F_GETOWN will return zero which is the default. It does exactly the same thing for normal file descriptors returned by open(2).
Then it either means: a) fcntl documentation should be updated to state that F_GETOWN command returns a non zero value if and only if it has been set by F_SETOWN. b) the kernel should maintain the value when it creates the socket I assume IPtables group phased out support for process matching rules because of the lack of support of b). From a security management (personal firewall...) stand point it would be good to keep the original pid and the "effective" pid (modified by F_SETOWN) of the creating process.