From: Ming Lei <ming.lei@redhat.com>
To: Jonathan Corbet <corbet@lwn.net>
Cc: Jens Axboe <axboe@kernel.dk>,
linux-block@vger.kernel.org,
ZiyangZhang <ZiyangZhang@linux.alibaba.com>,
Stefan Hajnoczi <stefanha@redhat.com>,
ming.lei@redhat.com
Subject: Re: [PATCH V3 6/6] ublk_drv: add mechanism for supporting unprivileged ublk device
Date: Wed, 4 Jan 2023 16:19:38 +0800 [thread overview]
Message-ID: <Y7U2mshx9s9rx++C@T590> (raw)
In-Reply-To: <87a62ze4ql.fsf@meer.lwn.net>
Hi Jonathan,
On Tue, Jan 03, 2023 at 01:35:14PM -0700, Jonathan Corbet wrote:
> I have one quick question...
>
> Ming Lei <ming.lei@redhat.com> writes:
>
> > In case of UBLK_F_UNPRIVILEGED_DEV:
> >
> > 1) for command UBLK_CMD_ADD_DEV, it is always allowed, and user needs
> > to provide owner's uid/gid in this command, so that udev can set correct
> > ownership for the created ublk device, since the device owner uid/gid
> > can be queried via command of UBLK_CMD_GET_DEV_INFO.
>
> Why do you have the user provide the uid/gid rather than just using the
> user's credentials directly? It seems a bit strange to me to let
> unprivileged users create devices with arbitrary ownership. What am I
> missing here?
It is one good question.
The original idea is to allow user A to create device for another user
B, and it still depends on user A's capability, such as, if the created
daemon can open the created device which is owned by user B actually.
The above behavior may be extended in future if there is such
requirement. I will switch to just allow to create device for the
current user in V4, then we can start with this easy/simple model.
BTW, that is exactly the current userspace implementation, only the
current uid/gid is passed.
https://github.com/ming1/ubdsrv/tree/unprivileged-ublk
Thanks,
Ming
next prev parent reply other threads:[~2023-01-04 8:20 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-07 12:32 [PATCH V3 0/6] ublk_drv: add mechanism for supporting unprivileged ublk device Ming Lei
2022-12-07 12:33 ` [PATCH V3 1/6] ublk_drv: remove nr_aborted_queues from ublk_device Ming Lei
2022-12-07 12:33 ` [PATCH V3 2/6] ublk_drv: don't probe partitions if the ubq daemon isn't trusted Ming Lei
2022-12-07 12:33 ` [PATCH V3 3/6] ublk_drv: move ublk_get_device_from_id into ublk_ctrl_uring_cmd Ming Lei
2022-12-07 12:33 ` [PATCH V3 4/6] ublk_drv: add device parameter UBLK_PARAM_TYPE_DEVT Ming Lei
2022-12-07 12:33 ` [PATCH V3 5/6] ublk_drv: add module parameter of ublks_max for limiting max allowed ublk dev Ming Lei
2022-12-07 12:33 ` [PATCH V3 6/6] ublk_drv: add mechanism for supporting unprivileged ublk device Ming Lei
2023-01-03 20:35 ` Jonathan Corbet
2023-01-04 8:19 ` Ming Lei [this message]
2022-12-12 3:59 ` [PATCH V3 0/6] " Ming Lei
2022-12-14 17:54 ` Jens Axboe
2022-12-15 0:35 ` 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=Y7U2mshx9s9rx++C@T590 \
--to=ming.lei@redhat.com \
--cc=ZiyangZhang@linux.alibaba.com \
--cc=axboe@kernel.dk \
--cc=corbet@lwn.net \
--cc=linux-block@vger.kernel.org \
--cc=stefanha@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.