Re: RFC: /dev/stdin, symlinks & permissions

[Denys Vlasenko <vda.linux@googlemail.com>]

On Tuesday 18 March 2008 15:32, Al Viro wrote:
> On Tue, Mar 18, 2008 at 08:54:45AM -0400, Theodore Tso wrote:
> 
> > The main issue is that at the moment, when you open /proc/self/fd/X,
> > what you get is a new struct file, since the inode is opened a second
> > time.  That is why you have to go through the access control checks a
> > second time, and why there are issues when you have /dev/stdin
> > pointing to a tty which was owned by user 1, and then when you su to
> > user 2, you get a "permission denied" error.
> > 
> > On other operating systems, opening /proc/self/fd/X gives you a
> > duplicate of the file descriptor.  That means that the seek pointer is
> > also duplicated.  This has been remarked upon before.  Linux 1.2 did
> > things "right" (as in, the same as Plan 9 and Solaris), but it was
> > changed in Linux 2.0.  Please see:
> > 
> > http://www.ussg.iu.edu/hypermail/linux/kernel/9609.2/0371.html
> 
> The real issue is that it was not Plan 9 semantics to start with.
> 
> See 9/port/devproc.c and 9/port/devdup.c; the former is procfs and
> while it does have <pid>/fd, the sucker is not a directory - it's
> a text file containing (more or less) the pathnames of opened files
> of that process.  The latter is an entirely different thing - it's
> a separate filesystem (#d instead of #p, FWIW).  There you have
> per-descriptor files to open and yes, that'll give you dup().  What
> you do not have there is per-process part.

/me puts his admin hat on

This issue (that /proc/self/fd/0,1,2 don't always work)
is a real problem. I was bitten by it more than once, thrying to do
something like:

setuidgid http_user httpd --log-to-file /proc/self/fd/2

Doesn't work. Which is sort of stupid - I _already_
have fd 2 open, what's the point in prohibiting me from
opening it again?

(As to why: there are lots of software which insist of logging
either to syslog or the file, whereas I really prefer to log
to stdout/stderr.)

> We could implement Plan 9 style dupfs, but to do that without excessive
> ugliness we'd need to change prototype of ->open() - it must be able to
> return a reference to struct file different from anything it got from
> caller; probably the least painful way would be to make it return

I am not an expert, so my question might be stupid, but:
can open("/proc/PID/fd/N") be special-cased to always succeed
if PID = current process' PID and fd N is already open?
--
vda