From owner-freebsd-hackers Fri Oct 24 10:42:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA06598 for hackers-outgoing; Fri, 24 Oct 1997 10:42:36 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.5.84]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA06593 for ; Fri, 24 Oct 1997 10:42:34 -0700 (PDT) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.7/8.8.7) id KAA17693; Fri, 24 Oct 1997 10:42:00 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp03.primenet.com, id smtpd017661; Fri Oct 24 10:41:50 1997 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id KAA14255; Fri, 24 Oct 1997 10:41:40 -0700 (MST) From: Terry Lambert Message-Id: <199710241741.KAA14255@usr08.primenet.com> Subject: Re: Possible SERIOUS bug in open()? (Big time bug) To: jamil@trojanhorse.ml.org (Jamil J. Weatherbee) Date: Fri, 24 Oct 1997 17:41:40 +0000 (GMT) Cc: tlambert@primenet.com, thorpej@nas.nasa.gov, joerg_wunsch@uriah.heep.sax.de, freebsd-hackers@FreeBSD.ORG In-Reply-To: from "Jamil J. Weatherbee" at Oct 23, 97 03:06:23 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > 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.