Date: Fri, 24 Oct 1997 17:41:40 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: jamil@trojanhorse.ml.org (Jamil J. Weatherbee) Cc: tlambert@primenet.com, thorpej@nas.nasa.gov, joerg_wunsch@uriah.heep.sax.de, freebsd-hackers@FreeBSD.ORG Subject: Re: Possible SERIOUS bug in open()? (Big time bug) Message-ID: <199710241741.KAA14255@usr08.primenet.com> In-Reply-To: <Pine.BSF.3.96.971023150036.3526A-100000@trojanhorse.ml.org> from "Jamil J. Weatherbee" at Oct 23, 97 03:06:23 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> No, the user open() should return error for somebody trying to open for > not read and not write. /dev/io gives the process IOPL on the basis that > it is able to open /dev/io, not do operations on it. This is an implied interface. > I think it is perfectly reasonable for the driver to expect its open > method called only if the user has permissions on the file. Permission dictate whether the user may read the file or write the file; the open method specific to the file dictates wheher the user can open the file. There aren't permission bits associated with "openable", only "readable" and "writeable". For /dev/io, where opening has side effects that it wouldn't if people were required to use ioctl()'s instead of inb/outb, or where the port range was always trapped and proxied after trap instead of untrapped, this wouldn't be a side effect. Generally, /dev/io exists because there isn't a DDX in the console code like there should be, and a couple of other similar uses. > When you start putting the responsibility on the driver for maintaining > the security of the system and not the kernel then your'e just asking > for trouble. A device must dictate the policy for its use in all implementations. The original thread where the OR'ed flags resulted in an (unexpected to the user) flags value of '3' was an issue of a device specific policy prohibiting simultaneous readability and writeability for the device. How would the kernel enforce security policy for a simplex audio device which could not be used bidirectionally? Device flags indicating its simplex nature? This seems to me to be an enforcement issue for the audio driver, not for the kernel. /dev/io is unique in that it depends, rightly or wrongly, on side effects instead of explicit action. I think /dev/io is poorly designed compared to the Linux I/O port mapping mechanism in this regard (for example). > Much like most drivers do not check to see if the device > being passed is valid once it is opened because it should always be > valid (under most circumstances). There's no accounting for programmers who don't know how to code for hot pluggability... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199710241741.KAA14255>