lkml.org 
[lkml]   [2016]   [Jun]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH 0/1] shiftfs: uid/gid shifting filesystem
Date
sorry, resending to list
I admit I am a newbie and not even a kernel developer, but for
curiosity: couldn't that uid shifting be done at the vfs layer when we
are mounting the fs in a different user ns?

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(+)
>



[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2016-06-01 15:21    [W:0.079 / U:0.324 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site