What happens when /etc/subuid doesn't exist? about lxd HOT 12 CLOSED

So what I'd expect there is:

• If any of /etc/subuid, /etc/subgid, newuidmap (in path) or newgidmap (in path) exist and one of the other doesn't, then fail saying that the host shadow configuration is inconsistent.
• If none of those exist, then assume you can take whatever range you want. Note that this will only work if lxd runs as root.

That's basically the same behavior LXC itself uses. We use newuidmap and /etc/subuid if they exist, if they don't, then only root can start unprivileged containers and no range check is done.

from lxd.

Do you think we need an actual spec on managing subuids/subgids which would also cover that fallback behaviour?

from lxd.

Quoting Stéphane Graber ([email protected]):

So what I'd expect there is:

• If any of /etc/subuid, /etc/subgid, newuidmap (in path) or newgidmap (in path) exist and one of the other doesn't, then fail saying that the host shadow configuration is inconsistent.
• If none of those exist, then assume you can take whatever range you want. Note that this will only work if lxd runs as root.

That sounds good to me.

There are other questions, such as

1. when we 'lxc start c1:l1 c2:l1', if l1's idmap is not available to lxd on c2, should
   l1 get shifted or should the migration fail
2. do we fail at startup if the kernel does not support user namespaces, or do we just
   wait and report an error if a container with an idmap tries to start.

from lxd.

Do you think we need an actual spec on managing subuids/subgids which would also cover that fallback behaviour?

I think so.

from lxd.

Ok, I'll work on an actual spec then.

As for your two questions:

1. My thought was that we'd record the allocation size in the container's config, so how large a range of uid and how large a range of gid we gave the container. Then on migration, we just need to ensure that the target host is able to provide us a range of the same size. The host uids/gids may differ but that's fine.

This implies that the actual data transfer is done in a uid and gid mapped namespace so that we transfer the data using the container's uids and gids rather than the host's.

2. So I think the user experience would actually be better if we let the daemon start but then had everything fail from that point on. My thought was also that status when run against a server rather than a container (so lxc status or lxc status some-remote:) would amongst other things, report the kernel version and the kernel features we care about (underlying filesystem, cgroup configuration, ...), having it print a sort of checklist of everything that should be there so that the user can easily figure out what's going on or why we fail to migrate to a given host due to mismatching features.

from lxd.

@tych0 ,

does doing the rootfs xfer in the mapped userns seem like a problem? (it means we need send and receive processes in mapped user namespaces, or else have to remap the rootfs)

@stgraber , you had been keen on btrfs send/receive being an option for migration. Does that break in the face of part 1 of your last comment?

from lxd.

Agreed with your second point - I prefer to let lxd start in that case.

from lxd.

On Fri, Nov 07, 2014 at 09:16:16AM -0800, hallyn wrote:

@tych0 ,

does doing the rootfs xfer in the mapped userns seem like a problem? (it means we need send and receive processes in mapped user namespaces, or else have to remap the rootfs)

Transferring the files should be fine, but you'll still need to exec
criu as root (unless, of course, we switch to the criu daemon model).

@stgraber , you had been keen on btrfs send/receive being an option for migration. Does that break in the face of part 1 of your last comment?

---

Reply to this email directly or view it on GitHub:
lxc/incus#19 (comment)

from lxd.

@hallyn: So it's indeed a problem for btrfs since unprivileged btrfs send/receive doesn't appear to be allowed at this time... So then the alternative is indeed to transfer outside the userns and uidmapshift it before container startup.

from lxd.

@tych0 In the userns model I was thinking about (which now seems to be a bad idea if only because of btrfs), only the transfer would have happened in the userns, the CRIU calls would have been done in the host namespace by lxd.

from lxd.

Cool, that sounds like it would work.
On Nov 7, 2014 6:29 PM, "Stéphane Graber" [email protected] wrote:

@tych0 https://github.com/tych0 In the userns model I was thinking
about (which now seems to be a bad idea if only because of btrfs), only the
transfer would have happened in the userns, the CRIU calls would have been
done in the host namespace by lxd.

—
Reply to this email directly or view it on GitHub
lxc/incus#19 (comment).

from lxd.

Github apparently failed to auto-close this one...

from lxd.