UID/GID mapping between host and lxc

[whostolemyname]

As obviously many users before me, I'm having trouble getting read/write access from a container to a zfspool. I have read through many of the posts concerning this topic both here within the forum and also on the internet. I've been following these instructions, but so far didn't manage to get the result I'd expect.
The goal is to move the data directory of a nextcloud instance out of the container and into a zfspool:

My lxc-config looks as follows:

arch: amd64
cores: 1
features: nesting=1
hostname: LXC.30-NC-AIO
memory: 1024
net0: name=eth0,bridge=vmbr0,firewall=1,hwaddr=BC:24:11:96:04:70,ip=dhcp,ip6=dhcp,type=veth
onboot: 1
ostype: debian
parent: SN_220-01
rootfs: local-zfs:subvol-220-disk-0,size=8G
snaptime: 1776523168
swap: 1024
unprivileged: 1
lxc.idmap: u 0 100000 33
lxc.idmap: g 0 100000 33
lxc.idmap: u 33 33 1
lxc.idmap: g 33 33 1
lxc.idmap: u 34 100034 65502
lxc.idmap: g 34 100034 65502
mp0: /even_disks/LXC_unprivileged/Nextcloud_data,mp=/mnt/Nextcloud_data

On the host:

cat /etc/subuid
root:33:1
root:100000:65536

cat /etc/subgid
root:33:1
root:100000:65536

On the host, the privileges are set :

ls -l /even_disks/LXC_unprivileged
total 1
drwxr-xr-x 2 www-data www-data 2 May  1 11:13 Nextcloud_data

The bind mountpoint is declared in the lxc-id.conf file. However, files do not appear, when on the host I do

ls -l /path/to/mounted/directory

.
The files within the zfspool do appear when additionally i do

pct set lxc-id -mp0 /path/to/storage/on/host,mp=/path/on/guest

but then in the guest the mapping fails

root@LXC:/# ls -l /mnt/Nextcloud_data
total 1
-rw-r--r-- 1 nobody nogroup 0 May  1 14:57 testfile.md

Funny enough, the whole thing works, if I simply do

chown -R 100033:100033 /path/to/storage/on/host

without any of the editing-the-config-business, but I'm wondering if it's a security issue and why then should it be necessary to write all the guides on how to do the mapping properly if it was so easy.
So: where am I going wrong?

 

[bl1mp]

Hi,

mhm that is a little bit confusing topic overall.
I hope this is helpful and does not simply repeat, what you already find in your analysis.
Subuid allows to use different user ids for the user on the host system as within the container.

This avoids escalation e.g. if an escape is happening from the container in context of the www-data user (uid 33 within the container), the escapes ends up in the context of the mapped user (e.g. 100033) on the host system.
Being in the context of user 100033 on the hosts, does provide far less privileges, than the host native www-data user (uid 33). This is even more worse e.g. for the root user, or personal user existing on the host as well as the container. This is also the fundamental difference of priviledged and unpriviledgte containers.
(https://linuxcontainers.org/lxc/manpages/man5/lxc.container.conf.5.html)

So it should absolutely do the job to use chown -R 100033:100033 /path/to/storage/on/hots.
Beside you might end up in situations, where you added files directly on the host,
and then you will always need to change the permissions manually.

If you are fine with that you are done.

----
If you consider this a continues pain, you might need to continue to tinker a bit.

From my understandment the following part

cat /etc/subuid
root:33:1

should only allow the host root user to allocate exactly uid 33 (www-data) on the host system

root:100000:65536

Instead allows the root user of the host on container creation to allocate uids in the range of 100000 to 165536.
Therefore container user 33 will be mapped to 100033 on the host, by enumeration.

In case you use a different user (uid 1000) for daily operations you can maybe try something like
lxc.idmap: u 33 1000 1
This should map user 33 (www-data) in the container to user 1000 on the host and you will most likely need to tinker with group/user permissions to ensure files written by the user on the host have correct permissions within the container for the www-data user. Maybe SGID will be a promising approach - e.g. inherit the groupid 100033.

During testing you should always double check, aka separately for read and write permissions from within the container.
You might find situations, where you are able to read from directorys created on the host, due to the anybody permissions, but you are not allowed to write to them, due to ownership issues. Otherwise you might spend some time, debugging and testing with false assumptions about permissions.

In case you intend to map directly to the hosts root user, you are basically breaking the security mechanism,
because every user capable to escape in the container context of www-data, then results as host root user.
So in that case you can bypass the effort with a priviledged container.

---
Usually I stay with the first approach.
The second one is how I usually deal with similar permission obstacles for fileservers, so you might find some deviating results during testing.

BR, Lucas