From: Ming Lei <[email protected]>
To: Stefan Hajnoczi <[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]>,
[email protected]
Subject: Re: [PATCH V2 0/1] ubd: add io_uring based userspace block driver
Date: Thu, 19 May 2022 10:42:22 +0800 [thread overview]
Message-ID: <YoWujjFArHaXuqYS@T590> (raw)
In-Reply-To: <[email protected]>
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.
Thanks,
Ming
next prev parent reply other threads:[~2022-05-19 2:42 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 [this message]
2022-05-19 9:46 ` Stefan Hajnoczi
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 \
--in-reply-to=YoWujjFArHaXuqYS@T590 \
[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