From owner-freebsd-hackers Thu Oct 23 10:31:40 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA12518 for hackers-outgoing; Thu, 23 Oct 1997 10:31:40 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.5.85]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA12513 for ; Thu, 23 Oct 1997 10:31:38 -0700 (PDT) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.7/8.8.7) id KAA13531; Thu, 23 Oct 1997 10:31:32 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp04.primenet.com, id smtpd013522; Thu Oct 23 10:31:30 1997 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id KAA26108; Thu, 23 Oct 1997 10:31:03 -0700 (MST) From: Terry Lambert Message-Id: <199710231731.KAA26108@usr02.primenet.com> Subject: Re: Possible SERIOUS bug in open()? To: thorpej@nas.nasa.gov Date: Thu, 23 Oct 1997 17:31:02 +0000 (GMT) Cc: dk+@ua.net, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199710222030.NAA20863@lestat.nas.nasa.gov> from "Jason Thorpe" at Oct 22, 97 01:30:28 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > For ioctls that don't change the state of the device, you absolutely want > to have it open for reading. I.e. if you have a device that can expose > sensitive information by ioctl, and you set the mode to 600, you won't > want random people opening it via the neat little open hole and performing > that read-only ioctl. What if I want to have a CDROM not mounted, allow users to mount it, but not allow users to eject it? ...and at the same time, I have a different drive that I want to allow users to both mount and eject? I need to hold a reference. The "lock against eject" operation is a side effect of an existing reference forcing the count over 1 for the device in question. So the short answer is "to obtain reference side effects without granting read/write access on the descriptor". Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.