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 --]
next prev parent 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