0

i'm running a Debian container in rootless mode and can't set an acl for groups and users besides my own group and user (at least it seems so). I started a bash in a container ( runc --root /var/slurm/run/ run --bundle ~/containers/test01/ test01) and then:

touch test.txt
setfacl -m g:adm:r-x test.txt

This leads to setfacl: test.txt: Invalid argument.

The group 'adm' exists. No other groups of /etc/groups/ works but my primary group setfacl -m u:root:r-x test.txt works fine.

That's the current user:

(base) root@runc:/# id
uid=0(root) gid=0(root) groups=0(root),65534(nogroup)

I first thought of Linux Caps and played around a bit, but I can't get it working. Capsh prints:

(base) root@runc:/# capsh --print
Current: cap_fowner,cap_kill,cap_net_bind_service,cap_sys_admin,cap_audit_write=ep
Bounding set =cap_fowner,cap_kill,cap_net_bind_service,cap_sys_admin,cap_audit_write
Ambient set =
Current IAB: !cap_chown,!cap_dac_override,!cap_dac_read_search,!cap_fsetid,!cap_setgid,!cap_setuid,!cap_setpcap,!cap_linux_immutable,!cap_net_broadcast,!cap_net_admin,!cap_net_raw,!cap_ipc_lock,!cap_ipc_owner,!cap_sys_module,!cap_sys_rawio,!cap_sys_chroot,!cap_sys_ptrace,!cap_sys_pacct,!cap_sys_boot,!cap_sys_nice,!cap_sys_resource,!cap_sys_time,!cap_sys_tty_config,!cap_mknod,!cap_lease,!cap_audit_control,!cap_setfcap,!cap_mac_override,!cap_mac_admin,!cap_syslog,!cap_wake_alarm,!cap_block_suspend,!cap_audit_read,!cap_perfmon,!cap_bpf,!cap_checkpoint_restore
Securebits: 00/0x0/1'b0
 secure-noroot: no (unlocked)
 secure-no-suid-fixup: no (unlocked)
 secure-keep-caps: no (unlocked)
 secure-no-ambient-raise: no (unlocked)
uid=0(root) euid=0(root)
gid=0(root)
groups=0(root),65534(nogroup),65534(nogroup),65534(nogroup),65534(nogroup)
Guessed mode: UNCERTAIN (0)

The same occurs of I want to set a acl for a user other than root.

Edit:

The hint regarding subgid might be helpful, at least it enhanced my understanding of user/group namespace mapping. Inside the container it seams that I have the following mapping:

(base) root@runc:/# cat /proc/self/gid_map
         0       1000          1

Here I can see that the group inside the container (0=root) is mapped to group id 1000 on the host system, and this is the group id of the user that started the rootless container. But there's a rang of 1, does this mean, this this single group can be mapped and can this be the cause why I can't chgrp adm foo?

Any hint is very appreciated.

Thanks a lot.

csmj
  • 11
  • 3
  • I would start with `man subgid`. – A.B Mar 08 '23 at 22:41
  • And use a simpler case: `touch foo; chgrp adm foo` : do you get the same EINVAL? – A.B Mar 08 '23 at 22:43
  • Yes, I get the same error: "chgrp: changing group of 'foo': Invalid argument". – csmj Mar 09 '23 at 08:48
  • acl are usually used when you have multiple users accessing to a filesystem, In a containers usually you have a single account, used to run the application, look like you want to use a container as a server . – c4f4t0r Apr 25 '23 at 09:18

1 Answers1

1

I finally solved it. I need to add uidMappings und gidMappings to to config.json, basically

        {
            "containerID": 1,
            "hostID": 231072,
            "size": 65536
        }

I just had a mapping from the root user within the container (id: 0) to the user that launched the container on the host (id: 1002). After adding additional mappings, the inside-container users could be mapped to ids that are valid on the host, too.

csmj
  • 11
  • 3