<div dir="ltr"><font face="georgia,serif"><br></font><br><div class="gmail_quote">On Tue, Jul 24, 2012 at 6:50 PM, Nadav Har'El <span dir="ltr"><<a href="mailto:nyh@math.technion.ac.il" target="_blank">nyh@math.technion.ac.il</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
This is a very interesting analysis, which I've never considered before.<br>
<br>
With pipes, we can perhaps argue the owner is wrong - that we're talking<br>
about a "fake" file so Linux could have invented a different owner for<br>
it.<br></blockquote><div><br>Everything is a file, as we know, even a pipe. The ownership is important, and was switched from (presumably) the euid to 0 at some point, causing the described problem. I don't know why and I'd like to know. or maybe it's a bug?<br>
<br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
However, there's an even bigger problem I think: Consider a situation<br>
where /proc/self/fd/2 points not to a pipe, but to an on-disk file:<br>
<br>
This file may belong to another user - it could have been passed to the<br>
current process by inheritance, or over a unix-domain socket or<br>
whatever. The current process *is* able to use the file descriptor, but<br>
it won't be able to open /proc/self/fd/2. And this can't even be fixed<br>
because the file this points to has certain owner and permission bits,<br>
and the kernel can't mess with those (like it theoretically could with the<br>
fake pipe file in your example).<br></blockquote><div><br>Isn't it the same as redirecting stderr to a real file and finding out that you don't have permissions to write to it?<br> <br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I do think this is a logic bug, and the reason why it came to be is,<br>
I believe, the following:<br>
<br>
Old versions of Unix following 8th Edition Research Unix had a similar<br>
feature called /dev/fd/... (see <a href="http://man.cat-v.org/unix_8th/4/fd" target="_blank">http://man.cat-v.org/unix_8th/4/fd</a>).<br>
There was a small, but for your purpose very important, difference<br>
between how /dev/fd worked then, and how /proc/self/fd/... works in<br>
Linux. "/dev/fd/2" wasn't a symbolic link (symbolic links were new to<br>
Unix at the time, and were not commonly used in any case). It was a<br>
special device (you had just 127 of them). When any process open()ed<br>
this device, the open would always succeed - the manual specified that<br>
open("/dev/fd/n", mode) is identical to dup(n). No additional permission<br>
testing would be done. /dev/fd/2 (and the identical /dev/stderr) would<br>
work exactly like you wanted.<br></blockquote><div><br>[By this time I have already grabbed a copy of APUE from a colleague's desk and found all of the above written there, including the statement that /dev/stderr was equivalent to /dev/fd/2. In fact, if memory serves, in the dark bygone days - possibly in the previous millennium - /dev/stderr used to be a symlink to /dev/fd/2. My memory has been noticed to be faulty occasionally in the past.]<br>
<br>This is exactly the difference - /dev/fd/2 was "special" and today's /dev/stderr is not. I generally subscribe to the philosophy of having as few special cases as possible, so treating /dev/stderr as a regular file (with open(), etc) rather than as a special file actually appeals to my sense of aesthetics. But then care should be taken not to fail where failure is not expected - in this case, permissions should be right.<br>
<br>[There may, theoretically, be a good security reason why the pipe belongs to root now, but I am not aware of any.]<br> <br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Linux deviated from this implementation for several reasons, one of them<br>
being that is a cool feature to do "ls -l /proc/self/fd" and see the<br>
names of all the open files. (there are several other important reasons<br>
that we can discuss if you want). This alternative implementation broke<br>
the correct behavior that Unix's /dev/fd/2 had - as you discovered.<br>
<br>
I don't know if Linux should be fixed at this point, as so much water<br>
has passed under the bridge since Unix implemented /dev/stderr<br>
correctly. I think /dev/stderr (and stdin, stdout) at least could<br>
easily have been fixed - even if the rest of /proc/fd is more difficult<br>
to fix.<br>
<br>
But I think it's important that this caveat is documented in proc(5),<br></blockquote><div><br>And in bash(1), as I pointed out in my reply to Amos.<br> <br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I remember when I learned Unix, it took me a while to understand what<br>
the strange incantations like<br>
<br>
something >filename 2>&1<br>
<br>
actually did. But when I finally understood how it works (i.e., uses<br>
dup(2)), I never had any problem with this syntax. </blockquote><div><br>I do not have any problem with the syntax. I do have to work with other people and less experienced folks may - and do - have problems with the admittedly rather arcane rules. Doing ">/dev/stderr" is much clearer and cleaner and readily readable and understandable (to say nothing of being very similar to g?awk that is so often used together with shell scripts - there "/dev/stderr" *is* treated specially). The desire to express myself clearly and cause as little confusion as possible led me to prefer ">/dev/stderr".<br>
<br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">And understanding<br>
what these do is important, because the authors of CSH obviously didn't<br>
and thus completely ruined that shell's redirection capabilities<br>
(see the very first entry in<br>
<a href="http://www.faqs.org/faqs/unix-faq/shell/csh-whynot/" target="_blank">http://www.faqs.org/faqs/unix-faq/shell/csh-whynot/</a> )<br></blockquote><div><br>Don't start... ;-)<br></div></div><br clear="all"><br>-- <br>
Oleg Goldshmidt | <a href="mailto:oleg@goldshmidt.org" target="_blank">pub@goldshmidt.org</a><br>
</div>