On Wed, May 14, 2014 at 10:15:27PM -0500, Seth Forshee wrote: > On Wed, May 14, 2014 at 10:17:31PM -0400, Michael H. Warfield wrote: > > > > Using devtmpfs is one possible > > > > solution, and it would have the added benefit of making container setup > > > > simpler. But simply letting containers mount devtmpfs isn't sufficient > > > > since the container may need to see a different, more limited set of > > > > devices, and because different environments making modifications to > > > > the filesystem could lead to conflicts. > > > > > > > > This series solves these problems by assigning devices to user > > > > namespaces. Each device has an "owner" namespace which specifies which > > > > devtmpfs mount the device should appear in as well allowing priveleged > > > > operations on the device from that namespace. This defaults to > > > > init_user_ns. There's also an ns_global flag to indicate a device should > > > > appear in all devtmpfs mounts. > > > > > I'd strongly argue that this isn't even a "problem" at all. And, as I > > > said at the Plumbers conference last year, adding namespaces to devices > > > isn't going to happen, sorry. Please don't continue down this path. > > > > I was just mentioning that to Serge just a week or so ago reminding him > > of what you told all of us face to face back then. We were having a > > discussion over loop devices into containers and this topic came up. > > It was the loop device use case that got me started down this path in > the first place, so I don't personally have any interest in physical > devices right now (though I was sure others would).
Why do you want to give access to a loop device to a container? Shouldn't you set up the loop devices before creating the container and then pass those mount points into the container? I thought that was how things worked today, or am I missing something? Giving the ability for a container to create a loop device at all is a horrid idea, as you have pointed out, lots of information leakage could easily happen. greg k-h -- 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/
