linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tejun Heo <tj@kernel.org>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Ric Wheeler <rwheeler@redhat.com>,
	Petr Matousek <pmatouse@redhat.com>, Kay Sievers <kay@redhat.com>,
	Jens Axboe <axboe@kernel.dk>,
	linux-kernel@vger.kernel.org,
	"James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>
Subject: Re: setting up CDB filters in udev (was Re: [PATCH v2 0/3] block: add queue-private command filter, editable via sysfs)
Date: Thu, 25 Oct 2012 11:00:45 -0700	[thread overview]
Message-ID: <20121025180045.GL11442@htj.dyndns.org> (raw)
In-Reply-To: <5088EC43.2010600@redhat.com>

(restoring cc lists)

Hey, Paolo.

On Thu, Oct 25, 2012 at 09:37:39AM +0200, Paolo Bonzini wrote:
> Il 24/10/2012 18:47, Tejun Heo ha scritto:
> > So, I'm still not convinced we need to go forward with full
> > configurability. All use cases you described can be covered with
> > per-class static filters + simple override switch to disable all,
> > which would result in a lot simpler implementation w/ much smaller
> > userland interface.
> 
> I'm not sure the userland interface would be smaller, and it would be
> more complex to get right:
> 
> 1) how do you override the default?  ioctl+SCM_RIGHTS or sysfs?

Disabling filters if opened by root and tranfering via SCM_RIGHTS
would be the simplest interface-wise (there's no new interface at
all).  Would that be too dangerous security-wise?

> 2) do you need to override the default to "no access", "full access" and
> "default access", or is a binary knob (default access/full access)
> sufficient?

Default / full should be enough, no?

> 3) what capabilities control the setting?

CAP_SYS_RAWIO seems to be a pretty good fit.

> > What's the rationale for full configurability?
> 
> Depending on the level of trust you have in your users, there are
> different policies that are applicable.  Even virtualization could have
> a range of choices like "permit only standard operations", "also permit
> UNMAP", "also permit persistent reservations", "permit everything
> including vendor specific commands"

I guess I just feel quite reluctant to expose another rather obscure
userland configurable in-kernel filter and at the same time I'm not
sure whether this is flexible enough.  What if a device is shared by
multiple virtual machines which are trusted at different levels?  What
if we end up actually having to filter cdb contents?

I'm not trying to block it at all cost but let's make sure we looked
into most possibilities before (re)adding this userland visible
interface.

Jens, James, what do you guys think?

Thanks.

-- 
tejun

  parent reply	other threads:[~2012-10-25 18:00 UTC|newest]

Thread overview: 37+ 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
     [not found]       ` <2007908429.13363375.1350637872646.JavaMail.root@redhat.com>
     [not found]         ` <20121019201058.GP13370@google.com>
     [not found]           ` <5087E093.50700@redhat.com>
     [not found]             ` <CAOS58YM5ZO9h0XUCNxV+6U3UzpeUen5ZuyqsNEUaJ81ux=QKvw@mail.gmail.com>
     [not found]               ` <5088EC43.2010600@redhat.com>
2012-10-25 18:00                 ` Tejun Heo [this message]
2012-10-25 18:35                   ` setting up CDB filters in udev (was Re: [PATCH v2 0/3] block: add queue-private command filter, editable via sysfs) Paolo Bonzini
2012-10-31 12:52                     ` Paolo Bonzini
2012-10-31 21:22                     ` Tejun Heo
2012-11-02 14:49                       ` Paolo Bonzini
2012-11-02 15:35                         ` Alan Cox
2012-11-02 16:48                           ` Tejun Heo
2012-11-02 17:21                             ` Alan Cox
2012-11-02 17:30                               ` Tejun Heo
2012-11-02 20:18                                 ` Alan Cox
2012-11-02 20:21                                   ` Tejun Heo
2012-11-02 20:48                                     ` Alan Cox
2012-11-02 22:59                                       ` Tejun Heo
2012-11-02 23:52                                         ` Alan Cox
2012-11-02 23:58                                           ` Tejun Heo
2012-11-03  0:19                                             ` Alan Cox
2012-11-03  0:23                                               ` Tejun Heo
2012-11-03  0:52                                                 ` Alan Cox
2012-11-02 16:51                         ` Tejun Heo
2012-11-02 17:49                           ` Paolo Bonzini
2012-11-02 17:53                             ` Tejun Heo
2012-11-03 13:20                               ` Paolo Bonzini
2012-11-03 14:50                                 ` Alan Cox
2012-11-05 11:08                                   ` Paolo Bonzini
2012-11-05 18:18                                   ` Tejun Heo
2012-11-05 20:12                                     ` Alan Cox
2012-11-05 20:09                                       ` Tejun Heo
2012-11-05 20:17                                         ` Alan Cox
2012-11-05 20:15                                           ` Tejun Heo
2012-11-05 18:26                                 ` Tejun Heo

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=20121025180045.GL11442@htj.dyndns.org \
    --to=tj@kernel.org \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=axboe@kernel.dk \
    --cc=kay@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=pmatouse@redhat.com \
    --cc=rwheeler@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).