From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Jens Axboe <axboe@suse.de>
Cc: Zinx Verituse <zinx@epicsol.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: ide-cd problems
Date: Tue, 03 Aug 2004 00:54:31 +0100 [thread overview]
Message-ID: <1091490870.1649.23.camel@localhost.localdomain> (raw)
In-Reply-To: <20040731200036.GM23697@suse.de>
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.
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.
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.
Alan
next prev parent reply other threads:[~2004-08-03 0:58 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-07-30 19:36 ide-cd problems Zinx Verituse
2004-07-31 15:36 ` Jens Axboe
2004-07-31 18:27 ` Zinx Verituse
2004-07-31 20:00 ` Jens Axboe
2004-07-31 21:02 ` Zinx Verituse
2004-08-01 4:07 ` Alexander E. Patrakov
2004-08-01 15:57 ` Jens Axboe
2004-08-02 3:20 ` Horst von Brand
2004-08-02 12:25 ` Jens Axboe
2004-08-02 20:44 ` Bill Davidsen
2004-08-02 13:45 ` tabris
2004-08-02 13:56 ` Jens Axboe
2004-08-02 14:26 ` Andreas Metzler
2004-08-02 14:33 ` Jens Axboe
2004-08-02 14:38 ` tabris
2004-08-02 14:50 ` Jens Axboe
2004-08-02 16:30 ` Bill Davidsen
2004-08-03 7:17 ` Jens Axboe
2004-08-02 17:16 ` Zinx Verituse
2004-08-05 5:40 ` Jens Axboe
2004-08-05 21:06 ` Alan Cox
2004-08-06 5:44 ` Jens Axboe
[not found] ` <20040806062331.GE10274@suse.de>
2004-08-06 12:14 ` Alan Cox
2004-08-06 14:32 ` Jens Axboe
2004-08-06 15:14 ` Charles Cazabon
2004-08-06 15:13 ` Jens Axboe
2004-08-07 14:01 ` Alan Cox
2004-08-06 17:26 ` dleonard
2004-08-06 22:47 ` Jens Axboe
2004-08-07 14:04 ` Alan Cox
2004-08-07 21:54 ` Alan Cox
2004-08-07 3:11 ` Jason L Tibbitts III
2004-08-09 8:39 ` Jens Axboe
2004-08-07 14:08 ` Alan Cox
2004-08-09 8:49 ` Jens Axboe
2004-08-02 23:54 ` Alan Cox [this message]
2004-08-03 5:53 ` Jens Axboe
2004-08-03 16:17 ` Zinx Verituse
2004-08-04 5:01 ` Jens Axboe
2004-08-05 15:52 ` Alan Cox
2004-08-05 17:46 ` Jens Axboe
2004-08-05 20:58 ` Alan Cox
2004-08-05 18:53 ` Bill Davidsen
2004-08-05 18:46 ` Bill Davidsen
2004-08-05 19:35 ` Jens Axboe
2004-08-05 21:02 ` Alan Cox
2004-08-06 5:42 ` Jens Axboe
2004-08-03 15:28 ` Doug Maxey
2004-08-03 17:28 ` Alan Cox
2004-08-09 20:24 ` Bill Davidsen
2004-08-02 16:41 ` Bill Davidsen
2004-08-03 15:50 ` Horst von Brand
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1091490870.1649.23.camel@localhost.localdomain \
--to=alan@lxorguk.ukuu.org.uk \
--cc=axboe@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=zinx@epicsol.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.