Re: ide-cd problems

[Jens Axboe <axboe@suse.de>]

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?

> 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.

Sorry, I think this model is totally bogus and I'd absolutely refuse to
merge any such beast into the block layer sg code.

-- 
Jens Axboe