https://bugzilla.novell.com/show_bug.cgi?id=728774
https://bugzilla.novell.com/show_bug.cgi?id=728774#c67
--- Comment #67 from Jeff Mahoney 2013-10-01 14:22:46 EDT ---
Created an attachment (id=561090)
--> (http://bugzilla.novell.com/attachment.cgi?id=561090)
[PATCH] vfs: allow /proc/pid/fd to dup a socket
I've asked Miklos for his take on this patch. It could be that I'll get laughed
out of the room. It at least works, though.
When a process has one of the stdio file descriptors set to one end
of a socket, it is prohibited from using /dev/std{in,out,err}.
For example, a script that does:
echo "some error" > /dev/stderr
.. will get ENXIO returned. The fact that this works for nearly every
other type of file except for sockets has been a source of confusion
among users and developers for some time. Other UNIX-like systems don't
make the distinction between socket and other files in their /dev/fd/
implementation, but this is largely due to using dup() rather than
handling it as symlink-open.
For a variety of reasons, the socket code depends on there being
a 1:1 mapping between a struct file and struct socket. It's possible
to rework the reference counting and export a few more socket
functions to allow a many:1 mapping, but we use the flags associated
with the file to determine if e.g. the socket is nonblocking. Having
multiple files with different semantics operating on the same file
would yield unexpected results.
As a result, the option that's left is to dup() the existing file
descriptor so that we preserve the 1:1 mapping. This is a special
case that is limited to sockets opened by the current process. The
symlink-open behavior has become a de-facto ABI and the dup
behavior can't be used universally as it would surprise users
expecting a /proc/pid/fd file open to return at offset 0 instead
of the f_pos of that file descriptor.
This patch adds the ability for a function in the lookup path to
set a new LOOKUP_DUP_FD flag and stash the file descriptor number
in the nameidata to provide the descriptor to dup after the open
fails.
It's hacky, but short of reworking the entire open path to accomodate
this special case, it's the cleanest solution. The FreeBSD kernel
reserves an int in their equivalent of task_struct for this, which is
even worse.
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.