NetBSD Problem Report #12999

Received: (qmail 6108 invoked from network); 21 May 2001 20:20:48 -0000
Message-Id: <200105212022.f4LKMBF03237@sigmet.ghs.com>
Date: Mon, 21 May 2001 13:22:11 -0700 (PDT)
From: Ross Harvey <ross@ghs.com>
Reply-To: ross@ghs.com
To: gnats-bugs@gnats.netbsd.org
Subject: /dev/rcd0a can be opened, but then ops get ENOTTY
X-Send-Pr-Version: 3.95

>Number:         12999
>Category:       kern
>Synopsis:       /dev/rcd0a can be opened, but then ops get ENOTTY
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    bouyer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon May 21 20:21:00 +0000 2001
>Closed-Date:    
>Last-Modified:  Sat Nov 17 17:14:00 +0000 2001
>Originator:     Ross Harvey
>Release:        all recent, including -current
>Organization:

>Environment:
	all, i think, i386 for sure
System: NetBSD sigmet 1.5U NetBSD 1.5U (skb) #28: Thu Apr 26 19:28:16 PDT 2001 ross@sigmet:/usr/ross/skb i386
Architecture: i386
Machine: i386
>Description:
	you can open /dev/rcd0a, for example, cdparanoia -g /dev/rcd0a ...,
	as it has a fake label, but then you can't do much with it because
	many ops are only supported on the RAW_PART, apparently so they will
	work with no media present.

	but this makes the error completely nonsensical .. if it isn't going
	to support the ops:
		(1) it shouldn't fake up a label for that partition
		(2) it shouldn't allow you to open it
>How-To-Repeat:
	# ktrace -i cdparanoia -g /dev/rcd0a -B 1-99
	# kdump
	watch it open the device successfully, but then
	fail to execute any ioctls, returning ENOTTY
>Fix:
	I might suggest...

	don't fake a label for 0a and do fail the open, or support the ops on
	all partitions. allowing the open and then failing the ops just makes
	it look like our system doesn't work, and gives absolutely no useful
	feedback to the user so he knows what to change
>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: kern-bug-people->bouyer 
Responsible-Changed-By: ross 
Responsible-Changed-When: Mon May 21 20:55:32 PDT 2001 
Responsible-Changed-Why:  
I'm reassigning this to Manuel, but please feel free to put it back 
to kern-bug-people or even to me if this isn't the right choice... 

// ross 

From: Manuel Bouyer <bouyer@antioche.eu.org>
To: Ross Harvey <ross@ghs.com>
Cc: gnats-bugs@gnats.netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: kern/12999: /dev/rcd0a can be opened, but then ops get ENODEV
Date: Sat, 17 Nov 2001 18:12:11 +0100

 On Mon, May 21, 2001 at 01:22:11PM -0700, Ross Harvey wrote:
 > 
 > >Number:         12999
 > >Category:       kern
 > >Synopsis:       /dev/rcd0a can be opened, but then ops get ENODEV
 > >Confidential:   no
 > >Severity:       serious
 > >Priority:       medium
 > >Responsible:    kern-bug-people
 > >State:          open
 > >Class:          sw-bug
 > >Submitter-Id:   net
 > >Arrival-Date:   Mon May 21 13:21:00 PDT 2001
 > >Closed-Date:
 > >Last-Modified:
 > >Originator:     Ross Harvey
 > >Release:        all recent, including -current
 > >Organization:
 > 	
 > >Environment:
 > 	all, i think, i386 for sure
 > System: NetBSD sigmet 1.5U NetBSD 1.5U (skb) #28: Thu Apr 26 19:28:16 PDT 2001 ross@sigmet:/usr/ross/skb i386
 > Architecture: i386
 > Machine: i386
 > >Description:
 > 	you can open /dev/rcd0a, for example, cdparanoia -g /dev/rcd0a ...,
 > 	as it has a fake label, but then you can't do much with it because
 > 	many ops are only supported on the RAW_PART, apparently so they will
 > 	work with no media present.
 > 
 > 	but this makes the error completely nonsensical .. if it isn't going
 > 	to support the ops:
 > 		(1) it shouldn't fake up a label for that partition
 > 		(2) it shouldn't allow you to open it
 > >How-To-Repeat:
 > 	# ktrace -i cdparanoia -g /dev/rcd0a -B 1-99
 > 	# kdump
 > 	watch it open the device successfully, but then
 > 	fail to execute any ioctls, returning ENOTTY

 I just started looking at this, sorry for the delay.
 In fact cdparanoia is getting ENOTTY here because it is trying to send
 SCSI commands to the device, and this is only allowed for raw partition.
 I'm not sure this is the kind of ops you want to allow for any opened
 partition, as this allows to do almost anything with the device like
 eject it even when it's still in use, or, for disks, read sectors outside
 of the partition or reformat it.
 You may want to allow arbitrary users to have read/write access to 
 a partition while not allowing them to send arbitrary SCSI commands to
 the device. So in the general case we want to restrict scsipi_do_ioctl()
 to the raw partition. I don't think we should special-case the CD device,
 but I'm open to discussion.

 --
 Manuel Bouyer <bouyer@antioche.eu.org>
 --
>Unformatted:

Home	PR Database Search