linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bart Van Assche <bvanassche@acm.org>
To: Paolo Bonzini <pbonzini@redhat.com>, linux-kernel@vger.kernel.org
Cc: linux-scsi@vger.kernel.org, Hannes Reinecke <hare@suse.com>,
	"Martin K. Petersen" <martin.petersen@oracle.com>,
	James Bottomley <James.Bottomley@hansenpartnership.com>
Subject: Re: [PATCH 3/3] block: add back command filter modification via sysfs
Date: Thu, 15 Nov 2018 21:46:04 -0800	[thread overview]
Message-ID: <1542347164.100259.32.camel@acm.org> (raw)
In-Reply-To: <1541867733-7836-4-git-send-email-pbonzini@redhat.com>

On Sat, 2018-11-10 at 17:35 +0100, Paolo Bonzini wrote:
> +sgio_read_filter (RW)
> +---------------------
> +When read, this file will display a list of SCSI commands (i.e. values of
> +the first byte of a CDB) that are always available for unprivileged users
> +via /dev/bsg, /dev/sgNN, or ioctls such as SG_IO and CDROM_SEND_PACKET.
> +When written, the list of commands will be modified.  The default filter
> +can be restored by writing "default" to the file; otherwise the input should
> +be a list of byte values or ranges such as "0x00-0xff".  In the latter case,
> +instead of replacing the filter completely you can add to the commands,
> +by writing a string that begins with '+', or remove them by writing a
> +string that begins with '-'.
> +
> +sgio_write_filter (RW)
> +----------------------
> +When read, this file will display a list of SCSI commands (i.e. values of
> +the first byte of a CDB) that are available for unprivileged users
> +when the block device is open for writing.  Writing to this file behaves
> +as for sgio_read_filter.

This seems like an unfortunate API choice to me. Let's have a look at the
following SBC commands:
* READ(6);  opcode 08h.
* READ(10); opcode 28h.
* READ(12); opcode A8h.
* READ(16); opcode 88h.
* READ(32); opcode 7fh; service action 0009h.

I do not know any application for which it would be useful to allow some but
not all of these commands. With the proposed interface however users will
have to examine all SCSI opcodes and for each opcode they will have to decide
whether or not it should be allowed. Additionally, for opcodes like 7fh that
represent multiple commands, users will have to decide whether they want to
allow all these commands or none. That's why I think that filtering SCSI
commands based on their CDB is an unfortunate choice. Would it be sufficient
for the use cases you are looking at to group SCSI commands as follows and to
enable/disable these commands per group:
* SCSI command that read information from the medium (e.g. READ) or from the
  controller (e.g. READ CAPACITY).
* SCSI commands that modify information on the medium (e.g. WRITE).
* SCSI commands that modify controller settings (e.g. MODE SELECT or SET
  TARGET PORT GROUPS).

Bart.

  reply	other threads:[~2018-11-16  5:46 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-10 16:35 [PATCH 0/3] SG_IO command filtering via sysfs Paolo Bonzini
2018-11-10 16:35 ` [PATCH 1/3] block: add back queue-private command filter Paolo Bonzini
2018-11-10 16:35 ` [PATCH 2/3] scsi: create an all-one filter for scanners Paolo Bonzini
2018-11-10 16:35 ` [PATCH 3/3] block: add back command filter modification via sysfs Paolo Bonzini
2018-11-16  5:46   ` Bart Van Assche [this message]
2018-11-16  7:00     ` Paolo Bonzini
2018-11-16 14:42       ` Bart Van Assche
2018-11-10 19:05 ` [PATCH 0/3] SG_IO command filtering " Theodore Y. Ts'o
2018-11-11 13:26   ` Paolo Bonzini
2018-11-11 14:14     ` Theodore Y. Ts'o
2018-11-16  0:26       ` Paolo Bonzini
2018-11-16  0:37         ` Bart Van Assche
2018-11-16  7:01           ` Paolo Bonzini
2018-11-16 17:35             ` Theodore Y. Ts'o
2018-11-11 13:14 ` Christoph Hellwig
2018-11-11 13:42   ` Theodore Y. Ts'o
2018-11-12  8:20     ` Christoph Hellwig
2018-11-12 10:17       ` Paolo Bonzini
2018-11-16  9:32         ` Christoph Hellwig
2018-11-16  9:45           ` Paolo Bonzini
2018-11-16  9:48             ` Christoph Hellwig
2018-11-16 17:43             ` Theodore Y. Ts'o
2018-11-16 18:17               ` Bart Van Assche
2018-11-16 21:08                 ` Paolo Bonzini
  -- strict thread matches above, loose matches on Subject: below --
2012-09-12 11:25 [PATCH 0/3] block: add queue-private command filter, editable " Paolo Bonzini
2012-09-12 11:25 ` [PATCH 3/3] block: add back command filter modification " Paolo Bonzini
2012-09-12 12:38   ` Alan Cox
2012-09-12 12:41   ` Alan Cox
2012-09-12 12:56     ` Paolo Bonzini
2012-09-12 11:23 [PATCH 0/3] block: add queue-private command filter, editable " Paolo Bonzini
2012-09-12 11:23 ` [PATCH 3/3] block: add back command filter modification " Paolo Bonzini

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=1542347164.100259.32.camel@acm.org \
    --to=bvanassche@acm.org \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=hare@suse.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=pbonzini@redhat.com \
    /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;
as well as URLs for NNTP newsgroup(s).