On Tue, Jul 24, 2012, Oleg Goldshmidt wrote about "Re: how to redirect in bash+crontab": > 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?
No, this cannot happen. write(2) cannot fail because of permission problems, only the open(2) can. Once a process has a file descriptor it can write it even if it could never open the original file itself. This is deliberate, and is often used - file descriptors are often passed between processes belonging to different users, either from parent to child (inheritance of file descriptors) or through UNIX-Domain Sockets (see Ancillary Messages in unix(7)). > 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. Like I explained, they *can't* be done right (when right mean "just like dup(2) would work) when it comes to ordinary files (not pipes). The only way to do this right, as far as I can see, is for /dev/stderr and friends *not* to be symbolic links. > [There may, theoretically, be a good security reason why the pipe belongs > to root now, but I am not aware of any.] I think it is meaningless security-wise, as the process already has the file descriptor itself and can use it, no matter who /proc/self/fd/2 belongs to. But of course I could be wrong here. > > But I think it's important that this caveat is documented in proc(5), > > And in bash(1), as I pointed out in my reply to Amos. Holy shit! I just noticed that bash(1) claims that ">/dev/stderr" doesn't actually open a file called /dev/stderr - but just does dup(2). Either this is not true, or you simply weren't using Bash - perhaps your crontab uses dash or something else. Nadav. -- Nadav Har'El | Tuesday, Jul 24 2012, 6 Av 5772 [email protected] |----------------------------------------- Phone +972-523-790466, ICQ 13349191 |To decide or not to decide, that is the http://nadav.harel.org.il |question. Or is it? _______________________________________________ Linux-il mailing list [email protected] http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
