Messages in this thread | | | From | Denys Vlasenko <> | Subject | Re: RFC: /dev/stdin, symlinks & permissions | Date | Sun, 23 Mar 2008 05:35:39 +0100 |
| |
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
| |