lkml.org 
[lkml]   [2004]   [Aug]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: ide-cd problems
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/

\
 
 \ /
  Last update: 2005-03-22 14:04    [W:0.092 / U:10.312 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site