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.
So what is your solution? Or do you believe that allowing users to have unmonitored access to devices is acceptable?
Sorry, I think this model is totally bogus and I'd absolutely refuse to
merge any such beast into the block layer sg code.