Messages in this thread |  | | Date | Tue, 3 Aug 2004 07:53:40 +0200 | From | Jens Axboe <> | Subject | Re: 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/
|  |