Jens Axboe wrote:
> On Tue, Aug 03 2004, Alan Cox wrote:
> 
>>On Sad, 2004-07-31 at 21:00, Jens Axboe wrote:
>>
>>>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.
>>
>>I disagree providing you turn it the other way around. The majority of
>>scsi commands have to be protected because you can destroy the drive
>>with some of them or bypass the I/O layers. (Eg using SG_IO to do writes
>>to raw disk to bypass auditing layers)
>>
>>So you need CAP_SYS_RAWIO for most commands. You can easily build a list
>>of sane commands for a given media type that are harmless and it fits
>>the kernel role of a gatekeeper to do that.
> 
> 
> So that's where we vehemently disagree - it fits the kernel role, if you
> allow it to control policy all of a sudden. And it's not easy, unless
> you do it per specific device (not just type, make and model).
> 
> 
>>Providing the 'allowed' function is driver level and we also honour
>>read/write properly for that case (so it doesnt bypass block I/O
>>restrictions and fail the least suprise test) then it seems quite
>>doable.
>>
>>For such I/O you'd then do
>>
>>	if(capable(CAP_SYS_RAWIO) || driver->allowed(driver, blah, cmdblock))
>>
>>If the allowed function filters positively "unknown is not allowed" and
>>the default allowed function is simply "no" it works.
> 
> 
> Until there's a new valid command for some device, in which case you
> have to update your kernel?

As opposed to now when a new command comes along and the driver doesn't 
generate it until you update your kernel? Reading a CD doesn't take 
exotic commands, and given the choice of having users able to send 
arbitrary commands to the device and not access it at all, I would say 
"not at all" would be good.
> 
> 
>>We'd end up with a list of allowed commands for all sorts of operations
>>that don't threaten the machine while blocking vendor specific wonders
>>and also cases where users can do stuff like firmware erase.

There was a note on another list titled "Why did this work?" (from 
memory) where someone accidentally run a firmware update as a normal 
user and it worked. While this was a benign event, it points out that 
there is a hole here far beyond my earlier worry that someone would 
update a CD-RW.
> 
> 
> Sorry, I think this model is totally bogus and I'd absolutely refuse to
> merge any such beast into the block layer sg code.
> 
So what is your solution? Or do you believe that allowing users to have 
unmonitored access to devices is acceptable?

Is this problem only in ide-cd, or does it affect other devices like 
ZIP, USB, etc, which do or may look like SCSI?

-- 
    -bill davidsen (davidsen@tmr.com)
"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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/