Messages in this thread |  | | Date | Mon, 21 May 2001 16:38:09 -0400 (EDT) | From | Alexander Viro <> | Subject | Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH] device arguments from lookup) |
| |
On Sun, 20 May 2001, Pavel Machek wrote:
> Hi! > > > A lot of stuff relies on the fact that close(open(foo, O_RDONLY)) is a > > no-op. Breaking that assumption is a Bad Thing(tm). > > Then we have a problem. Just opening /dev/ttyS0 currently *has* side > effects (it is visible on modem lines from serial port; it can block > you forever). > > If this assumption is somewhere, we should fix that place... Or fix > serial ports.
There is no way to fix it. If process A has ability to create and remove files in directory foo, then process B has no way to know what file it will actually open upon the attempt to open file in foo.
Example: you want to open /home/luser/barf and /home in on root filesystem (too many systems have such setup, and braindead as it is it _is_ valid). Luser creates a link to his tty (currently owned by luser, so no bullshit about "let's restrict link(2) to the case when target is owned by caller", please). After that he renames that link to barf.
If you've just decided to open it and rename() comes when you enter open(3) (in libc, still in userland), you _will_ end up opening luser's tty.
OTOH, behaviour of serial ports is required by standards.
All we can do is to open it in non-blocking mode and then checking whether we've got what we wanted. You _must_ call fstat(2) after opening a file that could be replaced under you. If you are not doing that (and open file in directory controled by somebody else) - you have an exploitable race. However, fstat() is too late to avoid side-effects of open() itself.
For serial ports O_NDELAY is enough to avoid that side effect. For something where it's not enough - well, too bad. Don't do it.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |