Taking host system uids during a setfacl in a container

1

Hello,

I’m having a problem with the setfacl command, which doesn’t seem to set the correct user uid. However, everything else seems OK.

Here are a few commands to show you :

root@jenkins-agent-8:~ # setfacl -m u:999:r-x /var/tmp/toto
root@jenkins-agent-8:~ # getfacl /var/tmp/toto
# file: var/tmp/toto
# owner: root
# group: root
user::rwx
user:1000999:r-x
group::r-x
mask::r-x
other::r-x

root@jenkins-agent-8:~ # setfacl -m u:jenkins:r-x /var/tmp/toto
root@jenkins-agent-8:~ # getfacl /var/tmp/toto
getfacl: Removing leading '/' from absolute path names
# file: var/tmp/toto
# owner: root
# group: root
user::rwx
user:1000999:r-x
group::r-x
mask::r-x
other::r-x

root@jenkins-agent-8:~ # getent passwd | grep jenkins
jenkins:x:999:994::/srv/data/jenkins:/bin/bash

root@jenkins-agent-8:~ # chown jenkins:jenkins /var/tmp/toto

root@jenkins-agent-8:~ # ll /var/tmp/
drwxr-xr-x+ 2 jenkins jenkins 2 Oct  9 18:06 toto

root@jenkins-agent-8:~ # ll -n /var/tmp/
drwxr-xr-x+ 2 999 994 2 Oct  9 18:06 toto

It seems that it’s only the setfacl that doesn’t set the right value.

Incus version:

root@srv-374:~ # incus --version
6.0.2
root@srv-374:~ # zfs --version
zfs-2.2.6-1~bpo12+2
zfs-kmod-2.2.6-1~bpo12+2

container config:

root@srv-374:~ # incus config show jenkins-agent-8
architecture: x86_64
config:
  image.architecture: amd64
  image.description: Debian bookworm amd64 (20241009_05:24)
  image.os: Debian
  image.release: bookworm
  image.serial: "20241009_05:24"
  image.type: squashfs
  image.variant: default
  security.nesting: "true"
  volatile.base_image: bea0f1696dc17d7a8002d8d0dd408ad51fa89212e24db1593831b0bed583a5a3
  volatile.cloud-init.instance-id: 9d303e99-d032-4ed4-9073-a2d7a9100ee2
  volatile.eth304.host_name: veth3a0373fc
  volatile.eth304.hwaddr: 00:16:3e:b6:e1:34
  volatile.idmap.base: "0"
  volatile.idmap.current: '[{"Isuid":true,"Isgid":false,"Hostid":1000000,"Nsid":0,"Maprange":1000000000},{"Isuid":false,"Isgid":true,"Hostid":1000000,"Nsid":0,"Maprange":1000000000}]'
  volatile.idmap.next: '[{"Isuid":true,"Isgid":false,"Hostid":1000000,"Nsid":0,"Maprange":1000000000},{"Isuid":false,"Isgid":true,"Hostid":1000000,"Nsid":0,"Maprange":1000000000}]'
  volatile.last_state.idmap: '[]'
  volatile.last_state.power: RUNNING
  volatile.uuid: af44b374-d0a2-4ceb-aaa6-8cc8fe7a4eaf
  volatile.uuid.generation: 598c27ca-f950-4758-98c4-ce9246ebbbb1
devices:
  root:
    path: /
    pool: default
    size: 2048GiB
    type: disk
ephemeral: false
profiles:
- net
- cpu-90-cores
- mem-300GiB
stateful: false
description: ""
2

I’ve just tried it on another machine with incus 6.5 version and I don’t have the problem:

root@test-setfacl:~# setfacl -m u:toto:r-x /var/tmp/toto
root@test-setfacl:~# getfacl /var/tmp/toto
getfacl: Removing leading '/' from absolute path names
# file: var/tmp/toto
# owner: root
# group: root
user::rwx
user:toto:r-x
group::r-x
mask::r-x
other::r-x

zfs version:
zfs-2.2.6-1
zfs-kmod-2.2.4-1

3

There’s IDMapping taking place, and the ID 999 in the container is shown as ID 1000000+999. Which is weird. It reveals to the container that the IDs are shifted by 1000000 while the container should not know that.

I can see that security.nesting is enabled. Did you have at some point also security.privileged?

4

No the container has been freshly created the only option we activate by default is security.nesting.

5

Do you need more information?