From: Paolo Bonzini <pbonzini@redhat.com>
To: Tejun Heo <tj@kernel.org>
Cc: linux-kernel@vger.kernel.org,
James Bottomley <James.Bottomley@HansenPartnership.com>,
Jens Axboe <axboe@kernel.dk>, Ric Wheeler <rwheeler@redhat.com>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
linux-scsi@vger.kernel.org
Subject: Re: [PATCH v2 0/3] block: add queue-private command filter, editable via sysfs
Date: Fri, 19 Oct 2012 05:07:09 -0400 (EDT) [thread overview]
Message-ID: <1954562860.13360801.1350637629926.JavaMail.root@redhat.com> (raw)
In-Reply-To: <20121019002250.GB13370@google.com>
> > In one use case, the administrator then needs the ability to configure
> > devices easily, for example to be much more restrictive on non-MMC
> > devices. It must be done with the same tools it uses for other
> > aspects of the policy---which will be a combination of DAC (Unix
> > permissions and ACLs) and sysfs. Different SCSI standards may give different
> > meanings for the same byte value, but a simple bitmap is enough for this.
> >
> > In the virtualization case, the problem is really that you want to
> > pass through everything or almost everything, while still running
> > as confined as possible (i.e. CAP_SYS_RAWIO is not a choice). But
> > in this case a more complex filtering can be done just as easily in
> > userspace, in the virtual machine monitor.
> >
> > One alternative is a ioctl to disable the filter altogether, to be
> > used together with SCM_RIGHTS file descriptor passing. This works in
> > the virtualization case but not for policy decisions. So this patch
> > series provides the sysfs knob. It is a tweaked revert of commit
> > 018e044 (block: get rid of queue-private command filter, 2009-06-26).
>
> If your use case at hand is mostly virtualization, I personally would
> prefer the latter solution instead of extending in-kernel SG_IO
> filter. It could be that I'm just not aware but I don't think there
> have been too many complaints regarding other use cases. This type
> of deep inspection and filtering has fairly strong tendency to be
> unpopular. Userland configurable one is even scarier and I don't
> think too many would know and make use of it in the end.
Actually I plan to set up the filtering in udev, so that we need not
pass through many MMC commands (some of which have completely different
meanings) to SBC devices. So it would really be useful.
Paolo
prev parent reply other threads:[~2012-10-19 9:07 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-25 15:30 [PATCH v2 0/3] block: add queue-private command filter, editable via sysfs Paolo Bonzini
2012-09-25 15:30 ` [PATCH v2 1/3] block: add back queue-private command filter Paolo Bonzini
2012-09-25 15:30 ` [PATCH v2 2/3] scsi: create an all-zero filter for scanners Paolo Bonzini
2012-09-25 15:30 ` [PATCH v2 3/3] block: add back command filter modification via sysfs Paolo Bonzini
2012-10-04 10:12 ` [PATCH v2 0/3] block: add queue-private command filter, editable " Paolo Bonzini
2012-10-19 0:22 ` Tejun Heo
2012-10-19 9:07 ` Paolo Bonzini [this message]
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=1954562860.13360801.1350637629926.JavaMail.root@redhat.com \
--to=pbonzini@redhat.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=axboe@kernel.dk \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=rwheeler@redhat.com \
--cc=tj@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;
as well as URLs for NNTP newsgroup(s).