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? 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. W dniu 01.06.2016 o 02:29, James Bottomley pisze: > [This patch is updated for the new VFS APIs in 4.7-rc1; it's also been > updated as Serge has been hammering on it] > > My use case for this is that I run a lot of unprivileged architectural > emulation containers on my system using user namespaces. Details here: > > http://blog.hansenpartnership.com/unprivileged-build-containers/ > > They're mostly for building non-x86 stuff (like aarch64 and arm secure > boot and mips images). For builds, I have all the environments in my > home directory with downshifted uids; however, sometimes I need to use > them to administer real images that run on systems, meaning the uids > are the usual privileged ones not the downshifted ones. The only > current choice I have is to start the emulation as root so the uid/gids > match. The reason for this filesystem is to use my standard > unprivileged containers to maintain these images. The way I do this is > crack the image with a loop and then shift the uids before bringing up > the container. I usually loop mount into /var/tmp/images/, so it's > owned by real root there: > > jarvis:~ # ls -l /var/tmp/images/mips|head -4 > total 0 > drwxr-xr-x 1 root root 8192 May 12 08:33 bin > drwxr-xr-x 1 root root 6 May 12 08:33 boot > drwxr-xr-x 1 root root 167 May 12 08:33 dev > > And I usually run my build containers with a uid_map of > > 0 100000 1000 > 1000 1000 1 > 65534 101000 1 > > (maps 0-999 shifted, then shifts nobody to 1000 and keeps my uid [1000] > fixed so I can mount my home directory into the namespace) and > something similar with gid_map. So I shift mount the mips image with > > mount -t shiftfs -o > uidmap=0:100000:1000,uidmap=65534:101000:1,gidmap=0:100000:100,gidmap=1 > 01:100101:899,gidmap=65533:101000:2 /var/tmp/images/mips > /home/jejb/containers/mips > > and I now see it as > > jejb@jarvis:~> ls -l containers/mips|head -4 > total 0 > drwxr-xr-x 1 100000 100000 8192 May 12 08:33 bin/ > drwxr-xr-x 1 100000 100000 6 May 12 08:33 boot/ > drwxr-xr-x 1 100000 100000 167 May 12 08:33 dev/ > > Like my usual unprivileged build roots and I can now use an > unprivileged container to enter and administer the image. > > It seems like a lot of container systems need to do something similar > when they try and provide unprivileged access to standard images. > Right at the moment, the security mechanism only allows root in the > host to use this, but it's not impossible to come up with a scheme for > marking trees that can safely be shift mounted by unprivileged user > namespaces. > > James > > --- > > fs/Kconfig | 8 + > fs/Makefile | 1 + > fs/shiftfs.c | 877 +++++++++++++++++++++++++++++++++++++++++++++ > include/uapi/linux/magic.h | 2 + > 4 files changed, 888 insertions(+) >
Attachment:
signature.asc
Description: OpenPGP digital signature
