Re: setting up CDB filters in udev (was Re: [PATCH v2 0/3] block: add queue-private command filter, editable via sysfs)

[Alan Cox <alan@lxorguk.ukuu.org.uk>]

On Fri, 2 Nov 2012 13:21:31 -0700
Tejun Heo <tj@kernel.org> wrote:

> Hey,
> 
> On Fri, Nov 02, 2012 at 08:18:24PM +0000, Alan Cox wrote:
> > a - there are lots of cases you want to allow only a subset of commands.
> 
> Care to spell them out.  At least the cases Paolo listed should be
> served by what's described.
> 
> > b - if you are using a BPF filter which is the obvious way to do it then
> > the flexibility comes for free without any extra complexity as the kernel
> > provides a generic implementation, and even a JIT for complex cases.
> 
> Yeah, sure, but it's all about what tool to use where and maybe it's
> my ignorance about the problem space but it's difficult for me to
> believe that we need full-blown BPF filter here when this is the only
> activity we've got in a decade.

If you look back through the archive you'll find people have been
spending a good decade bitching about the lack of filter configurability
and trying to get someone else to fix it.

The BPF filter is simpler than just about any other implementation
because the tools exist and are used for lots of other things and it has
an API that is precisely defined as well as kernel calls to run the
filter.

Some reasons for it

- giving people access to parts of disks
- allowing access to specific vendor specific commands on certain
  non-standard CD and DVD drives so they can be used for burning but you
  can't trash them
- giving end users minimal access to things like SMART but only on drives
  where it is safe
- giving a user a SCSI disk or partition to play with but preventing them
  issuing weird ass commands that can disrupt other devices in the fabric
  (like drive to drive transfers, some kinds of resets, management
  commands)
- minimising the ability of a VM to do damage if compromised while
  maximising its raw access to a device



Alan