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

-
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.125 / U:4.520 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site