When scanning for uid/gid maps, discard if not mapped in the user namespace

[jameinel]

Required information

• Distribution: xenial
• The output of "lxc info" or if that fails:
  driver: lxc
  driverversion: 2.0.6
  kernel: Linux
  kernelarchitecture: x86_64
  kernelversion: 4.4.0-62-generic
  server: lxd
  serverpid: 3426
  serverversion: "2.8"
  storage: zfs
  storageversion: "5"

(lxc info has gotten awfully long, but I can include it if you want)

Issue description

A brief description of what failed or what could be improved.

Steps to reproduce

I'm currently running Xenial with the backported 2.8 LXD. If I try to do nested containers with Juju (juju bootstrap lxd; juju add-machine --to lxd:0) it is failing with:

        machine-status:
          current: provisioning error
          message: 'Failed to change ownership of: /var/lib/lxd/containers/juju-ab3dc6-0-lxd-0/rootfs'
          since: 15 Feb 2017 10:13:21+04:00

If I set "security.privileged: true" in the profile, then I'm able to create a nested container. I thought "security.nested" was intended to be all you really needed to do.

When I track through the lxd code the line appears to be from:
shared/util_linux.go ShiftOwner()
which only seems to be called from:
shared/idmapset_linux.go doUidshiftIntoContainer

A simpler way to trigger this seems to be:

$ lxc launch ubuntu:x --config security.nesting=true nest-test
$ lxc exec nest-test bash
$$ lxc launch ubuntu:x inside-test
Generating a client certificate. This may take a minute...
If this is your first time using LXD, you should also run: sudo lxd init
To start your first container, try: lxc launch ubuntu:16.04

Creating inside-test
Retrieving image: 100%error: Failed to change ownership of: /var/lib/lxd/containers/inside-test/rootfs

Note that if I set "security.privileged=true" along with "security.nested=true" then it does work to launch a nested container.

[lagunax]

i think that nest-test is unprivileged container, does it?

[jameinel]

nest-test is (security.privileged=false, security.nested=true) because the goal was to be able to nest containers without having to set privileged=true. Otherwise, why would you have a separate setting?

[jameinel]

If I make it (security.privileged=true, security.nested=true) then I can successfully create the container 'inside-test'.

[lagunax]

i don't know exactly, but i think that you can do it with chown -R for /var/lib/lxd/containers/inside-test. unpriviledge level limits rights of conteiner to users rights. priviledget level gives root's rights

[stgraber]

You only need security.nesting=true at the host level, but if you do that and your container doesn't have enough uid/gid to carve a second allocation, then you need the NESTED containers to be marked as security.privileged so they re-use their parent's container allocation instead of attempting to get their own.

This situation is detected and handled properly when you run "lxd init" inside a container. It will detect that it's got insufficient uid/gid and ask you (defaulting to Yes) if you want to use the same uid/gid map as the parent.

[stgraber]

stgraber@castiana:~$ lxc launch ubuntu:16.04 first -c security.nesting=true
Creating first
Starting first

stgraber@castiana:~$ lxc exec first bash
root@first:~# lxd init
Name of the storage backend to use (dir or zfs) [default=dir]: 

We detected that you are running inside an unprivileged container.
This means that unless you manually configured your host otherwise,
you will not have enough uid and gid to allocate to your containers.

LXD can re-use your container's own allocation to avoid the problem.
Doing so makes your nested containers slightly less safe as they could
in theory attack their parent container and gain more privileges than
they otherwise would.

Would you like to have your containers share their parent's allocation (yes/no) [default=yes]? 
Would you like LXD to be available over the network (yes/no) [default=no]? 
Do you want to configure the LXD bridge (yes/no) [default=yes]? 
Warning: Stopping lxd.service, but it can still be activated by:
  lxd.socket
LXD has been successfully configured.
root@first:~# lxc launch images:alpine/edge nested
Generating a client certificate. This may take a minute...
If this is your first time using LXD, you should also run: sudo lxd init
To start your first container, try: lxc launch ubuntu:16.04

Creating nested
Starting nested        
root@first:~# 

[jameinel]

It feels like at a minimum there could be a better message on launching the container than "failed to chown /.../rootfs" It is nice that you give a message in "lxd init", though that doesn't quite solve what to do for automated deployments. I suppose some of that is us coming up with a reasonable policy, and messaging that appropriately. John =:->

…

On Wed, Feb 15, 2017 at 9:03 PM, Stéphane Graber ***@***.***> wrote: ***@***.***:~$ lxc launch ubuntu:16.04 first -c security.nesting=true Creating first Starting first ***@***.***:~$ lxc exec first bash ***@***.***:~# lxd init Name of the storage backend to use (dir or zfs) [default=dir]: We detected that you are running inside an unprivileged container. This means that unless you manually configured your host otherwise, you will not have enough uid and gid to allocate to your containers. LXD can re-use your container's own allocation to avoid the problem. Doing so makes your nested containers slightly less safe as they could in theory attack their parent container and gain more privileges than they otherwise would. Would you like to have your containers share their parent's allocation (yes/no) [default=yes]? Would you like LXD to be available over the network (yes/no) [default=no]? Do you want to configure the LXD bridge (yes/no) [default=yes]? Warning: Stopping lxd.service, but it can still be activated by: lxd.socket LXD has been successfully configured. ***@***.***:~# lxc launch images:alpine/edge nested Generating a client certificate. This may take a minute... If this is your first time using LXD, you should also run: sudo lxd init To start your first container, try: lxc launch ubuntu:16.04 Creating nested Starting nested ***@***.***:~# — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#2885 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAMYfWuVm4ZpllWZ6XR9zUxKO46kby6Cks5rcy_-gaJpZM4MBWj5> .

[stgraber]

We should be able to tweak LXD's uid/gid map handling to ignore maps that aren't available due to the underlying ids not being mapped in the namespace. That'd then have LXD fallback to only supporting privileged containers and be able to fail a bit earlier.