Encountered new LXD INIT question - what is impact

LXD
1

I have enabled one container for nesting.

I enter that container and installed LXD.

When I did LXD INIT… I encountered the following message:

$ sudo lxd init

Would you like to use LXD clustering? (yes/no) [default=no]:
Do you want to configure a new storage pool? (yes/no) [default=yes]:
Name of the new storage pool [default=default]:
Would you like to connect to a MAAS server? (yes/no) [default=no]:
Would you like to create a new local network bridge? (yes/no) [default=yes]: no
Would you like to configure LXD to use an existing bridge or host interface? (yes/no) [default=no]: yes
Name of the existing bridge or host interface: eth0

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 uids and gids 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]:

Before I proceed I’d like to understand the answer to two questions:

  1. When it says “unless you manually configured your host otherwise, you will not have enough uids and gids to allocate to your containers” what exactly would I have had to do to take this approach?

  2. What would answering NO prevent me from doing ?

For #1 is it saying:
edit /etc/subuid and /etc/subgid in the HOST and bump them there then do something ?

2

If the container has less than 2*65536 consecutive uids/gids assigned to it, it can’t make unprivileged containers as it won’t have a range of 65536 uid/gid that’s separate from its own range.

If you did get the container more than that many uids/gids, then you can use LXD normally, if not, answer yes and the nested containers will run in privileged more where they’re effectively running with the same uid/gid range as the parent container.

Assigned more uids/gids when using the deb package would indeed require a change of /etc/subuid, /etc/subgid on the host and a restart of LXD.

When using the snap, LXD ignores those files and default to a billion uid/gid, avoiding such problems.

Though even in this case, if your container uses security.idmap.isolated, then the range size would default to 65k and so be insufficient unless you set security.idmap.size to at least 2*65536.

3

Thanks for the explanation Stehane !