On Sun, Feb 22, 2015 at 9:01 AM, James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: > On Tue, 2014-12-02 at 15:47 -0800, Andy Lutomirski wrote: >> This should hopefully be a short topic, and it's possible that it'll >> be settled by the time LSF/MM comes around, but: >> >> There's a fair amount of interest from different directions for >> allowing filesystems with a backing store to be mounted (in the >> mount-from-scratch sense, not the bind-mount sense) in a user >> namespace. For example, Seth has patches to allow unprivileged FUSE >> mounts. There are a few issues here, for example: >> >> - What happens to device nodes in those filesystems? > > You have to allow device nodes in mount namespaces. However, not all > devices should be present, only the ones the owner of the namespace is > allowed to either see (read only) or control (read/write). I agree that you need to allow device nodes, but I'm not sure that you need to allow device nodes on filesystems with backing store. Every recent distro should work with devtmpfs (admittedly, we don't know how devtmpfs should work in a container), but tmpfs is a decent alternative. In any event, sticking device nodes on ext4 is asking for trouble with dynamic minors and such. > > The specific problem for container security is allowing the user who can > write to the device also to mount it ... because that lets them inject > data known to cause a kernel crash and bring down the entire system or > worse. The current solution is simply not to allow the owner both to > write and mount, but this is becoming increasingly untenable using > loopback images with containers for cascading overlays like docker does. I see this as a separate issue. If the kernel has no implementation bugs, this would be a nonissue :) --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
