From owner-freebsd-hackers Sun Aug 18 00:21:10 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA00606 for hackers-outgoing; Sun, 18 Aug 1996 00:21:10 -0700 (PDT) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id AAA00583 for ; Sun, 18 Aug 1996 00:21:07 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id JAA25834; Sun, 18 Aug 1996 09:20:54 +0200 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id JAA23432; Sun, 18 Aug 1996 09:20:48 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.5/8.6.9) id JAA15260; Sun, 18 Aug 1996 09:19:48 +0200 (MET DST) From: J Wunsch Message-Id: <199608180719.JAA15260@uriah.heep.sax.de> Subject: Re: XMCD problem on FreeBSD 2.1.5 To: xmcd@bazooka.amb.org (Xmcd Admin) Date: Sun, 18 Aug 1996 09:19:48 +0200 (MET DST) Cc: freebsd-hackers@freebsd.org (FreeBSD hackers), bwithrow@BayNetworks.com Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <9608180050.AA20324@bazooka.amb.org> from Xmcd Admin at "Aug 17, 96 05:50:19 pm" X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Xmcd Admin wrote: > Xmcd should be quite secure even when the setuid root. I have no doubt in this. Anyway, the ioctl commands are there to provide a more secure and more general way (same API also for non-SCSI drives). And the basic rule is that a program should not be setuid if it is not needed. Of course, it is a matter of the FreeBSD `port' to correct this for the average user. > While xmcd does support using the CD-audio ioctls under FreeBSD, > if you have a SCSI CD-ROM drive you lose a couple of features > when running in that mode. Namely, the SCSI pass-through method > gives you channel routing and caddy lock/unlock capabilities. If you miss some features, they should better be implemented on the ioctl level, instead of going the other way round. I have no idea what you mean by `channel routing', but the caddy lock/unlock feature is there implicitly (if i'm not very mistaken) since the device is locked while it is held open. (There's currently what i would call a bug in the `eject' ioctl implementation in that it lets you eject a locked drive. This is easy to fix however.) I consider using direct SCSI commands the most ugly method to use, though of course, for many operating systems it's your only chance. > I don't have an explanation for the EINVAL error from the CDIOREADTOCENTRYS > ioctl. [...] I am not familiar with the wcd driver > but if you have the source code you can check the wcdioctl() routine > to see why it is choking on the CDIOREADTOCENTRYS ioctl... wcd is the ATAPI CD-ROM driver. Apparently, it doesn't use direct SCSI commands. :-) It looks like a bug in this driver, and that's been my first reply to Robert's message. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)