On Fri, May 16, 2014 at 09:31:37PM -0700, Eric W. Biederman wrote: > Greg Kroah-Hartman <gre...@linuxfoundation.org> writes: > > > On Fri, May 16, 2014 at 01:49:59AM +0000, Serge Hallyn wrote: > >> > I think having to pick and choose what device nodes you want in a > >> > container is a good thing. Becides, you would have to do the same thing > >> > in the kernel anyway, what's wrong with userspace making the decision > >> > here, especially as it knows exactly what it wants to do much more so > >> > than the kernel ever can. > >> > >> For 'real' devices that sounds sensible. The thing about loop devices > >> is that we simply want to allow a container to say "give me a loop > >> device to use" and have it receive a unique loop device (or 3), without > >> having to pre-assign them. I think that would be cleaner to do using > >> a pseudofs and loop-control device, rather than having to have a > >> daemon in userspace on the host farming those out in response to > >> some, I don't know, dbus request? > > > > I agree that loop devices would be nice to have in a container, and that > > the existing loop interface doesn't really lend itself to that. So > > create a new type of thing that acts like a loop device in a container. > > But don't try to mess with the whole driver core just for a single type > > of device. > > Yes. Something like devpts (without the newinstance option). Built to > allow unprivileged users to create loopback devices.
That's where I started, and I've got code, so I guess I'll clean it up and send patches. If the stance is that only system-wide CAP_SYS_ADMIN gets to do privileged block device ioctls, including reading partitions on a block device which has been assigned to a contiainer, then I guess that approach works well enough. > There is still a huge kettle of fish in with verifying a filesystem is > safe from a hostile user that has acess to the block device while the > filesystem is mounted. > > Having a few filesystems that are robust enough to trust with arbitrary > filesystem corruption would be very interesting. > > I assume unprivileged and hostile users because if you trusted the real > root inside of your container this would not be an issue. > > Eric > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
