public inbox for [email protected]
 help / color / mirror / Atom feed
From: Stefan Hajnoczi <[email protected]>
To: Ming Lei <[email protected]>
Cc: Jens Axboe <[email protected]>,
	[email protected], [email protected],
	Harris James R <[email protected]>,
	[email protected],
	Gabriel Krisman Bertazi <[email protected]>,
	ZiyangZhang <[email protected]>,
	Xiaoguang Wang <[email protected]>
Subject: Re: [PATCH V2 0/1] ubd: add io_uring based userspace block driver
Date: Thu, 19 May 2022 10:46:41 +0100	[thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <YoWujjFArHaXuqYS@T590>

[-- Attachment #1: Type: text/plain, Size: 3053 bytes --]

On Thu, May 19, 2022 at 10:42:22AM +0800, Ming Lei wrote:
> On Wed, May 18, 2022 at 04:49:03PM +0100, Stefan Hajnoczi wrote:
> > On Wed, May 18, 2022 at 08:53:54PM +0800, Ming Lei wrote:
> > > On Wed, May 18, 2022 at 11:45:32AM +0100, Stefan Hajnoczi wrote:
> > > > On Wed, May 18, 2022 at 03:09:46PM +0800, Ming Lei wrote:
> > > > > On Tue, May 17, 2022 at 03:06:34PM +0100, Stefan Hajnoczi wrote:
> > > > > > Here are some more thoughts on the ubd-control device:
> > > > > > 
> > > > > > The current patch provides a ubd-control device for processes with
> > > > > > suitable permissions (i.e. root) to create, start, stop, and fetch
> > > > > > information about devices.
> > > > > > 
> > > > > > There is no isolation between devices created by one process and those
> > > > > 
> > > > > I understand linux hasn't device namespace yet, so can you share the
> > > > > rational behind the idea of device isolation, is it because ubd device
> > > > > is served by ubd daemon which belongs to one pid NS? Or the user creating
> > > > > /dev/ubdbN belongs to one user NS?
> > > > 
> > > > With the current model a process with access to ubd-control has control
> > > > over all ubd devices. This is not desirable for most container use cases
> > > > because ubd-control usage within a container means that container could
> > > > stop any ubd device on the system.
> > > > 
> > > > Even for non-container use cases it's problematic that two applications
> > > > that use ubd can interfere with each other. If an application passes the
> > > > wrong device ID they can stop the other application's device, for
> > > > example.
> > > > 
> > > > I think it's worth supporting a model where there are multiple ubd
> > > > daemons that are not cooperating/aware of each other. They should be
> > > > isolated from each other.
> > > 
> > > Maybe I didn't mention it clearly, I meant the following model in last email:
> > > 
> > > 1) every user can send UBD_CMD_ADD_DEV to /dev/ubd-control
> > > 
> > > 2) the created /dev/ubdcN & /dev/udcbN are owned by the user who creates
> > > it
> > 
> > How does this work? Does userspace (udev) somehow get the uid/gid from
> > the uevent so it can set the device node permissions?
> 
> We can let 'ubd list' export the owner info, then udev may override the default
> owner with exported info.
> 
> Or it can be done inside devtmpfs_create_node() by passing ubd's uid/gid
> at default.
> 
> For /dev/ubdcN, I think it is safe, since the driver is only
> communicating with the userspace daemon, and both belong to same owner.
> Also ubd driver is simple enough to get full audited.
> 
> For /dev/ubdbN, even though FS isn't allowed to mount, there is still
> lots of kernel code path involved, and some code path may not be run
> with unprivileged user before, that needs careful audit.
> 
> So the biggest problem is if it is safe to export block disk to unprivileged
> user, and that is the one which can't be bypassed for any approach.

Okay.

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2022-05-19  9:46 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-17  5:53 [PATCH V2 0/1] ubd: add io_uring based userspace block driver Ming Lei
2022-05-17  5:53 ` [PATCH V2 1/1] " Ming Lei
2022-05-17 10:00   ` Ziyang Zhang
2022-05-17 12:55     ` Ming Lei
2022-05-18  5:53       ` Ziyang Zhang
2022-05-17  8:01 ` [PATCH V2 0/1] " Christoph Hellwig
2022-05-17 14:06 ` Stefan Hajnoczi
2022-05-18  7:09   ` Ming Lei
2022-05-18 10:45     ` Stefan Hajnoczi
2022-05-18 12:53       ` Ming Lei
2022-05-18 15:49         ` Stefan Hajnoczi
2022-05-19  2:42           ` Ming Lei
2022-05-19  9:46             ` Stefan Hajnoczi [this message]
2022-05-18  6:38 ` Liu Xiaodong
2022-05-18 13:18   ` Ming Lei
2022-05-23 14:56     ` Liu Xiaodong
2022-05-24  2:59       ` Ming Lei
2022-05-18  9:26 ` Stefan Hajnoczi
2022-05-19 13:33 ` Ming Lei

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 \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    /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