Re: cd burning with plextor drives.

[Douglas Gilbert <dougg@torque.net>]

Linus Torvalds wrote:
> 
> On Sat, 29 Jul 2006, Douglas Gilbert wrote:
>> Command filtering has always been dubious.
> 
> No it has not.
> 
> Command filtering falls under the _very_ non-dubious heading of "of 
> _course_ we have to do it". There is absolutely zero doubt about it at 
> all. 
> 
> You literally have two choices:
>  - you can filter commands
>  - you can disallow all command access for non-specific-capability users.
> 
> Those are the two choices. There really is no third choice. The only 
> question is the details of _how_ you do the filtering and/or disallowing.
> 
>> If a user has read write permissions on
>> a full device (not just a partition in it) why shouldn't
>> they be able to send any (SCSI/ATA/...) pass through
>> command to it?
> 
> They have read-write access to the PLATTER. 
> 
> The fact that you may have access to write data to a disk does _not_ mean 
> that you must necessarily be able to set the password on the disk so that 
> nobody else can ever read or write data to that disk without your 
> permission.

See below. Non-root users do not usually have read
or write permissions to a _disk_. We were talking
about a different class of devices: cd/dvd drives.

> Quite frankly, if you don't see that as an "obvious", and that I'm 100% 
> right when I say that you have the above _two_ choices, and that your 
> choice simply is not a choice at all, but total idiocy, then I don't know 
> what to say.

Well if you want to filter, I'll be happy to find
flaws, both over and under filtering. Are you sure
SCSI commands are being sent through the pass through?
How about ATA commands tunnelled in SCSI commands
(already supported by libata). There was recent talk
of tunnelling SAS SMP functions through SCSI (SSP)
to name another (ab)use.

> Put another way: you will remove that command filtering in 
> block/scsi_ioctl.c only in a kernel that I don't maintain, or by disabling 
> it in some way that is so hidden that I won't notice. Because I'm not so 
> stupid as to think that it's ok for normal users to set driver passwords 
> or rewrite the disk firmware just because they have write permissions to 
> the device. That's pretty damn final.

You weren't at the storage summit. As stated in other
posts to this thread it was concluded that command
filtering is a flawed strategy. With that consensus
that leaves the "disallow all command access for
non-specific-capability users" option.

> But you can try to _improve_ the filtering. We've certainly done that 
> before. Quite frankly, I don't think there's a lot there that can be 
> improved upon any more, but it's certainly an option that we could change 
> that filtering to be (a) per-device and (b) allow root to explicitly 
> change it on a per-machine and per-device setting, with the current 
> filtering rules being just the "default rules".

By current rules I suppose you mean the block SG_IO rules. Do you really
mean "per-device" as in /dev/hdc or "per-device-type" as in disk versus
cd/dvd drive? The current rules are skewed towards MMC so far that
they are broken in that some SBC (i.e. hard disk) modifying commands
can slip through in the guise of innocent MMC commands.

> Then you could encode any additional rules you want in a /sbin/hotplug 
> script or something. But the filtering isn't going _anywhere_, and what 
> you suggest is just totally and utterly insane.

Sounds like you are playing the man and not the ball.
Why didn't you jump on either of these posts:
http://marc.theaimsgroup.com/?l=linux-scsi&m=115417174425242&w=2
http://marc.theaimsgroup.com/?l=linux-scsi&m=115418046812126&w=2
Hmm?


As you are no doubt aware, disk permissions and cd/dvd drive
permissions are set up differently:

$ df -hT
Filesystem    Type    Size  Used Avail Use% Mounted on
/dev/hda2     ext3     19G   15G  3.4G  82% /

$ ls -l /dev/hda /dev/hda2
brw-r----- 1 root disk 3, 0 Jul 29 05:14 /dev/hda
brw-r----- 1 root disk 3, 2 Jul 29 09:14 /dev/hda2

This email has been saved on /dev/hda2 but I don't have
permissions on it. I can't send any pass through commands
to /dev/hda or /dev/hda2 as a non-root user (unless
my user is in group 'disk' and the command only needs
O_RDONLY which rules out the SCSI WRITE command).

Here is my cd/dvd combo drive:

$ ls -l /dev/hdc
brw------- 1 dougg disk 22, 0 Jul 29 09:14 /dev/hdc

The GUI (kde of FC5) was started as user 'dougg' but
I'm writing this email as user 'torque' so I can't
access that cd/dvd drive at the pass through level.


There is another class of commands that the sg driver does
require CAP_SYS_RAW_IO capability for. Those are the ones
that do collateral damage. A bus reset command comes to
mind (also ATA soft resets on PATA can take out the other
device on the cable). IMO collateral damage is something
the OS should take special care with.

Doug Gilbert