How exactly should I map uid/gid for lxd (non-snap)?

LXD
#1

Hi,

How exactly should I setup /etc/sub{u,g}id for lxd ?

Here (Idmaps for user namespace - LXD documentation), it seems like I should make an entry for the current user, the one who run the container.
However a guide (https://www.cyberciti.biz/faq/how-to-add-or-mount-directory-in-lxd-linux-container/) to mount a shared dir to the container (read/write) sugggest I should have root:1000:1 since lxd daemon is running as root, which seems true also.

So I’m not sure I understand the config correctly.

#2

The only entries that matter to LXD are the ones for the root user.
The matching entries you may sometimes see for the lxd user are there just to ease tracking by the system administrator (figure out what was added to root for LXD vs what was added for other reasons).

#3

Hmm, then the doc here Idmaps for user namespace - LXD documentation

If some but not all of /etc/subuid, /etc/subgid, newuidmap (path lookup) and newgidmap (path lookup) can be found on the system, LXD will fail the startup of any container until this is corrected as this shows a broken shadow setup.

and Arch wiki Linux Containers - ArchWiki

Create both /etc/subuid and /etc/subgid to contain the mapping to the containerized uid/gid pairs for each user who shall be able to run the containers.

is both wrong ?

In case it’s as you say, how should I setup the entry for root user ? Does root:1000:1 (to share directory with host) have any security downside ? Do I need to allow 65536 range ?

#4

/etc/subuid and /etc/subgid need to have at least 65536 entries for the root user or you’ll end up with non-functional containers.

So at a minimum you need something like:

root:100000:65536

Then if you also need LXD to be able to map the uid 1000 inside of containers, you need to append:

root:1000:1

And yeah, that comes with a security downside. Once a container has their raw.idmap setup to make use of that host uid 1000, it will allow the container to run actual processes as that user which means it can use ulimit to apply system-wide restrictions to the uid, potentially impacting processes in other containers or even on the host.
Also, in the unlikely event of a kernel issue allowing an escape from the container, rather than only have uids and gids which are unused on the host and so don’t have write permissions anywhere, you’ll now be able to use that uid 1000 which actually has some amount of write access to the host.

It’s usually not much of a concern as such uid sharing is often done to purposefully expose such writable space over to the container in the first place, but it’s something to keep in mind.

#5

Thanks for the information !

So this mean LXD understand the entry for lxd user as an “alias” to the entry for “root” user ? Or do I need to keep both ?

Going out of the subject here just for being curious (: May I ask how exactly the mapping is done in the case both root:100000:65536 and root:1000:1 exist ? Does this mean 1001 will then be mapped to 1001000 instead of 1001001 ?

#6

LXD doesn’t care at all about the lxd entry, in fact, nothing does.

As I said above:

The matching entries you may sometimes see for the lxd user are there just to ease tracking by the system administrator (figure out what was added to root for LXD vs what was added for other reasons).

#7

LXD will indeed shift things around by one, so you’ll now have one more valid uid at the end of the range.

You can look at /proc/self/uid_map to see what’s actually configured in the kernel.