how to redirect in bash+crontab

[Nadav Har'El]

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
nyh at math.technion.ac.il             |-----------------------------------------
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