On Tue, Jul 24, 2012, Oleg Goldshmidt wrote about "how to redirect in bash+crontab": > Is it a bug? If so, is it a kernel bug (it creates the /proc hierarchy, > right?) or a cron bug (faulty effective id?) or a bash bug (should > /dev/stderr be handled specially)? Were there (security?) reasons to change > the ownership of the pipe (and permissions on the character tty device in > Fedora, while we are at it)?
This is a very interesting analysis, which I've never considered before. With pipes, we can perhaps argue the owner is wrong - that we're talking about a "fake" file so Linux could have invented a different owner for it. However, there's an even bigger problem I think: Consider a situation where /proc/self/fd/2 points not to a pipe, but to an on-disk file: This file may belong to another user - it could have been passed to the current process by inheritance, or over a unix-domain socket or whatever. The current process *is* able to use the file descriptor, but it won't be able to open /proc/self/fd/2. And this can't even be fixed because the file this points to has certain owner and permission bits, and the kernel can't mess with those (like it theoretically could with the fake pipe file in your example). I do think this is a logic bug, and the reason why it came to be is, I believe, the following: Old versions of Unix following 8th Edition Research Unix had a similar feature called /dev/fd/... (see http://man.cat-v.org/unix_8th/4/fd). There was a small, but for your purpose very important, difference between how /dev/fd worked then, and how /proc/self/fd/... works in Linux. "/dev/fd/2" wasn't a symbolic link (symbolic links were new to Unix at the time, and were not commonly used in any case). It was a special device (you had just 127 of them). When any process open()ed this device, the open would always succeed - the manual specified that open("/dev/fd/n", mode) is identical to dup(n). No additional permission testing would be done. /dev/fd/2 (and the identical /dev/stderr) would work exactly like you wanted. Linux deviated from this implementation for several reasons, one of them being that is a cool feature to do "ls -l /proc/self/fd" and see the names of all the open files. (there are several other important reasons that we can discuss if you want). This alternative implementation broke the correct behavior that Unix's /dev/fd/2 had - as you discovered. I don't know if Linux should be fixed at this point, as so much water has passed under the bridge since Unix implemented /dev/stderr correctly. I think /dev/stderr (and stdin, stdout) at least could easily have been fixed - even if the rest of /proc/fd is more difficult to fix. But I think it's important that this caveat is documented in proc(5), explaining how open(/proc/self/fd/n) differs from from dup(n) (>&2 in your example of course uses dup(2)). Unfortunately, last time I sent a bug report to the Linux manual pages project I was ignored, so I don't know how successful you'll be if you try. > Until it is resolved one way or another it looks like ">&2" is much > preferable to ">/dev/stderr". I find it quite unexpected. I actually like > /dev/stderr better since it is less cryptic. I remember when I learned Unix, it took me a while to understand what the strange incantations like something >filename 2>&1 actually did. But when I finally understood how it works (i.e., uses dup(2)), I never had any problem with this syntax. And understanding what these do is important, because the authors of CSH obviously didn't and thus completely ruined that shell's redirection capabilities (see the very first entry in http://www.faqs.org/faqs/unix-faq/shell/csh-whynot/ ) -- Nadav Har'El | Tuesday, Jul 24 2012, 6 Av 5772 [email protected] |----------------------------------------- Phone +972-523-790466, ICQ 13349191 |Don't accept your dog's admiration as http://nadav.harel.org.il |conclusive evidence that you're wonderful _______________________________________________ Linux-il mailing list [email protected] http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
