lkml.org 
[lkml]   [2004]   [Sep]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] allow root to modify raw scsi command permissions list
On Wed, 15 Sep 2004 16:32:24 -0400
Peter Jones <pjones@redhat.com> wrote:

> It'd be pretty easy to add device-type defaults to my patch, and make
> them registered by the individual drivers.

Even this won't get us very far. Maybe we could probably find suitable
defaults for most modern hardware, but this still won't help users of
older or non-standard hardware.
For example, remember LG's abuse of CACHE_FLUSH for firmware updates.

Here I've done some grepping over cdrecord and k3b:
http://marc.theaimsgroup.com/?l=linux-kernel&m=109269018602502&w=2

>
> 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.

Per device-type filters are unavoidable (unless we deny everything by
default).
This is especially true for MODE_SELECT. See here:
http://marc.theaimsgroup.com/?l=linux-kernel&m=109274414601613&w=2

>
> 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.

Why not deny everything and have a "smart" user space tool that assigns
filters to devices during startup? The tool's database could be updated
regularly by distributors.

>
> > A good reminder of why the whole thing is a mess :-)
>
> It sure is.

IMHO all the more reason to keep all knowledge about individual devices
(and thus the need to provide updates) out of the kernel.

BTW: My impression was, that in the long term applications should be
adopted to work safely with increased capabilities. Is this still the
goal?

mfg
-
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:06    [W:0.053 / U:0.048 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site