From: Peter Jones <pjones@redhat.com>
To: Jens Axboe <axboe@suse.de>
Cc: Kai Makisara <Kai.Makisara@kolumbus.fi>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] allow root to modify raw scsi command permissions list
Date: Wed, 15 Sep 2004 16:32:24 -0400 [thread overview]
Message-ID: <1095280344.20046.32.camel@localhost.localdomain> (raw)
In-Reply-To: <20040915195024.GA3899@suse.de>
On Wed, 2004-09-15 at 21:50 +0200, Jens Axboe wrote:
> > This could also be done in your approach. One possibility would be to
> > start with empty filter and call from CD/DVD registering a function that
> > sets the filter you currently have as default. This would be both flexible
> > and safe.
>
> I think that's a really nice idea. I've said right from the beginning
> that the command tables cannot even be per-device type, at least with
> CDROMs we have examples of commands with different meanings. But at
> least with a device-type default list we're a little closer.
It'd be pretty easy to add device-type defaults to my patch, and make
them registered by the individual drivers.
I'm just not sure I see the point in doing it. Without them, you get a
_somewhat_ reasonable set of defaults if you don't want to mess with it,
and distros can easily set their own per-device tables for each device
type, vendor specific commands, etc. It's even pretty simple to just
deny everything, if that's what distro maintainers or sysadmins want to
do.
Not doing it also means that the device driver code itself needs less
maintenance, and won't need to be updated every time some vendor comes
up with a new READ command. That makes it easier if for example distros
decide to push new command tables as updates, I think.
> A good reminder of why the whole thing is a mess :-)
It sure is.
--
Peter
next prev parent reply other threads:[~2004-09-15 20:34 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-14 14:51 [PATCH] allow root to modify raw scsi command permissions list Peter Jones
2004-09-14 22:43 ` Marc Ballarin
2004-09-15 17:08 ` Peter Jones
2004-09-15 19:14 ` Kai Makisara
2004-09-15 19:49 ` Peter Jones
2004-09-15 20:49 ` Kai Makisara
2004-09-15 19:50 ` Jens Axboe
2004-09-15 20:32 ` Peter Jones [this message]
2004-09-16 9:33 ` Marc Ballarin
2004-09-15 21:08 ` [PATCH-NEW] " Marc Ballarin
2004-09-15 21:38 ` Alan Cox
2004-09-15 23:03 ` Peter Jones
2004-09-15 22:23 ` Alan Cox
2004-09-15 23:33 ` Marc Ballarin
2004-09-15 23:36 ` Peter Jones
2004-09-16 12:21 ` Marc Ballarin
2004-09-16 15:10 ` Marc Ballarin
2004-09-16 17:36 ` Peter Jones
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=1095280344.20046.32.camel@localhost.localdomain \
--to=pjones@redhat.com \
--cc=Kai.Makisara@kolumbus.fi \
--cc=axboe@suse.de \
--cc=linux-kernel@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox