On Mon, Jun 06, 2016 at 03:02:30PM -0700, James Bottomley wrote: > On Sun, 2016-06-05 at 22:11 +0100, Djalal Harouni wrote: > > On Wed, Jun 01, 2016 at 12:41:00PM -0400, James Bottomley wrote: > > > On Wed, 2016-06-01 at 18:21 +0200, Michał Zegan wrote: > > > > As I sent a reply in a ... wrong way, I do it again. my question > > > > was: > > > > Why isn't it done at the vfs layer when you mount the fs in > > > > different > > > > userns, instead of using a separate filesystem for it? > > > > > > Well, that is what this patch does: > > > > > > http://thread.gmane.org/gmane.linux.kernel/2214882 > > > > > > However, the reason it doesn't work for me is that I want to be > > > able to > > > unpack the image into a subdirectory (so I'm not dedicating a whole > > > filesystem for this). This is primarily for a docker hack IBM is > > > working on to allow each container instance to use a separate > > > uid/gid > > > range, so I need something that behaves much more like a bind > > > mount. > > I thought that you were using a loop device ? > > No, for Architectural emulation containers, I use file roots, so > they're subdirectories of my home directory. The interesting issues > Serge discovered are on ext4, which I needed a loop device to reproduce > (my home directory is xfs) if that's where the confusion arises? Ok then, but yeh for security it's better to have a different backing store... it allows somehow to protect the host too... > Thinking about containers in general, a significant amount use bind > mounted file roots because that's a nice use case that hypervisors > can't match without clusterable filesystems. However, I do know some > containers that are block image based, so whatever solution is chosen > has to support both. Yeh, but I may say that with overlayfs things changed a bit... actually the bind mount of today is kind of overlayfs mount... that most containers support by default, but yeh it solves the case of one shared portable filesystem image that you shift mount on its different backing store and use it as a lower layer for overlayfs to gain sharing capabilities (hence why that RFC does the shift only when we need the actual access...) and each container with its own upper layer... you endup automatically by a default clean reset image and snapshots... > > that's precisely one of the main case that's solved with that > > solution... mount the portable fs image into a loop device, set the > > shift which will be only active into that subdirectory... > > > > > > > > I believe it could be useful to be able to mount all filesystems > > > > in userns with autoshifted uids, although I do not know security > > > > implications for that usage. > > > > > > As long as you don't need to subdivide the volume, it works nicely. > > > However, from a security point of view, that entire volume is now > > > effectively freely writeable by anyone who can set up a userns. If > > > you follow the shiftfs route, you can break off writeable > > > subdirectories for each namespace shift, but they can't cross over > > > into writing subdirectories that belong to other user namespaces > > > (assuming the uids are fully segregated). > > > > As said in the other email, I'm not really sure about the use case at > > all... but I give you this quick test with: > > https://gist.githubusercontent.com/tixxdz/6b84c2c3bd6cb987c82255602ec > > 70f23/raw/97c9ab76878f9d7415583c00b22ca0e4a948847b/userns_test.c > > > > $ mkdir shifted-fedora-tree && sudo mount -t shiftfs > > -ouidmap=0:1000000:65536,gidmap=0:1000000:65536 ~/fedora-tree/ > > shifted-fedora-tree > > This is basically what I do for my container roots. However, after > that I tend to set them up with scripts. I've attached my latest build > -container script at the bottom. As you can see from my script, all my > build containers are in /home/jejb/containers. Ok, thanks! -- Djalal Harouni http://opendz.org -- 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
