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:
signature.asc
Description: PGP signature
