From owner-freebsd-hackers Sat Jun 17 04:42:33 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id EAA21651 for hackers-outgoing; Sat, 17 Jun 1995 04:42:33 -0700 Received: from hda.com (hda.com [199.232.40.182]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id EAA21645 for ; Sat, 17 Jun 1995 04:42:30 -0700 Received: (dufault@localhost) by hda.com (8.6.11/8.3) id HAA11954; Sat, 17 Jun 1995 07:38:36 -0400 From: Peter Dufault Message-Id: <199506171138.HAA11954@hda.com> Subject: Re: SCIOCCOMMAND ioctl - permission denied To: gena@NetVision.net.il (Gennady B. Sorokopud) Date: Sat, 17 Jun 1995 07:38:35 -0400 (EDT) Cc: tomppa@zeta.fidata.fi, hackers@FreeBSD.org, gena@NetVision.net.il In-Reply-To: from "Gennady B. Sorokopud" at Jun 17, 95 11:59:58 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1636 Sender: hackers-owner@FreeBSD.org Precedence: bulk Gennady B. Sorokopud writes: > > Hello! > > I'm author of xmcd port to FreeBSD platform. > I received some reports from users that claims that xmcd SCSI > interface does not work any more on 2.0.5R. > > After some checking i find out that SCIOCCOMMAND ioctl always fail > with "permission denied". > > Looking at /sys/scsi/scsi_ioctl.c line 260: > > /* If we can't write the device we can't permit much: > */ > if (cmd != SCIOCIDENTIFY && !(flags & FWRITE)) > return EACCES; > > After commenting out this 2 lines and recompiling the kernel > xmcd started to work fine. > > All i need to know is how to call this ioctl so it will not fail. You are probably opening the device O_RDONLY. The SCIOCCOMMAND ioctl beginning in 2.05 is considered 'destructive' and requires write access to the device (even for a CD-ROM). This is different from write permission to open the device. This is because I can't tell which SCIOCCOMMANDs do things (change the mode on the device, eject the CD, etc) that you want to restrict. Otherwise someone could open the CD device read-only, allow removal, change the modes, eject the device, etc. I can't protect based on whether you read or write data, since many destructive commands don't transfer data. Sorry, I should have considered this problem with existing programs. I hate to see your program break this way on 2.05. Are there any ideas for better ways to handle this? Peter -- Peter Dufault Real Time Machine Control and Simulation HD Associates, Inc. Voice: 508 433 6936 dufault@hda.com Fax: 508 433 5267