Re: ide-cd problems

[Bill Davidsen]

Jens Axboe wrote:
> On Sat, Jul 31 2004, Zinx Verituse wrote:
>
> > On Sat, Jul 31, 2004 at 05:36:10PM +0200, Jens Axboe wrote:
> >
> > > On Fri, Jul 30 2004, Zinx Verituse wrote:
> > >
> > > > I'm going to bump this topic a bit, since it's been a while..
> > > > There are still some issues with ide-cd's SG_IO, listed from
> > > > most important as percieved by me to least:
> > > >
> > > > * Read-only access grants you the ability to write/blank media in the drive
> > > > * (with above) You can open the device only in read-only mode.
> > >
> > > That's by design. Search linux-scsi or this list for why that is so.
> >
> > The only thing I can find on the linux-scsi list is refering to sg
> > devices, which are on a different device node from the non-generic
> > device.  This means you can still allow users read access to the disk
> > without allowing them to send random commands to the disk -- this isn't
> > currently possible with the IDE interface, since the device with
> > generic access is the same as the one with the original read/cdrom
> > commands access.
> >
> > As it is, it's impossible grant users read-only access to an IDE cd-rom
> > without allowing them to do things like replacing the firmware with a
> > malicious/non-working one.
> >
> > Generic access allowing such things is fine; but only if we can grant
> > non-generic access without granting generic access.
>
>
> If you want it to work that way, you have the have a pass-through filter
> in the kernel knowing what commands are out there (including vendor
> specific ones). That's just too ugly and not really doable or
> maintainable, sorry.
>
> If you have access to issue ioctls to the device, you have access to
> send it arbitrary commands - period.
Let me try this again... To do the normal "reasonable" things associated 
with raw read, the standard SCSI command set includes commands in the 
read and seek sets which seem to be what is needed. These are standard, 
and I fail to see how allowing them, and only them, could be so 
complicated in the case where only read access is allowed. There is no 
need to allow vendor commands or any kind to permit programs such as 
checks and backups of various kinds to be used.

I think the same is true of write, filtering out anything but the set of 
write commands in the common SCSI command set is fine, and in the rare 
case where it isn't, I'm happy to say that raw write capability is the 
answer.

  read does not imply write
  write does not imply anything but data

firmware reload, low level format, spin in the other direction, all 
would require capability.

If you disagree with the above in some technical way, please clarify. If 
you just are opposing filtration on general principles because you run 
everything as root or don't believe in levels of security, I sure can't 
change your mind if you're willing to disagree with Alan.

--
   -bill davidsen (davidsen@xxxxxxx)
"The secret to procrastination is to put things off until the
 last possible moment - but no longer"  -me
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/