Podman in rootless mode on LXC container

[marceliszpak]

I have a problem with starting podman as a non-root user on LXC. I have tried it on Debian and Fedora based LXC without success. Installation gone fine, on root account works fine but every podman command from non-root account ends with:

cockpit@Test:~$ podman info
ERRO[0000] running `/usr/bin/newuidmap 4852 0 1000 1 1 165536 65536`: newuidmap: write to uid_map failed: Operation not permitted
Error: cannot set up namespace using "/usr/bin/newuidmap": exit status 1

on root account

cockpit@Test:~$ sudo podman info
[sudo] password for cockpit:
host:
arch: amd64
buildahVersion: 1.28.2
cgroupControllers:
- cpu
- memory
- pids
cgroupManager: systemd
cgroupVersion: v2
conmon:
package: conmon_2.1.6+ds1-1_amd64
path: /usr/bin/conmon
version: 'conmon version 2.1.6, commit: unknown'
cpuUtilization:
idlePercent: 98.59
systemPercent: 0.41
userPercent: 1
cpus: 2
distribution:
codename: bookworm
distribution: debian
version: "12"
eventLogger: journald
hostname: Test
idMappings:
gidmap: null
uidmap: null
kernel: 6.5.11-8-pve
linkmode: dynamic
logDriver: journald
memFree: 8258920448
memTotal: 8589934592
networkBackend: netavark
ociRuntime:
name: crun
package: crun_1.8.1-1+deb12u1_amd64
path: /usr/bin/crun
version: |-
crun version 1.8.1
commit: f8a096be060b22ccd3d5f3ebe44108517fbf6c30
rundir: /run/crun
spec: 1.0.0
+SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +YAJL
os: linux
remoteSocket:
exists: true
path: /run/podman/podman.sock
security:
apparmorEnabled: false
capabilities: CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT
rootless: false
seccompEnabled: true
seccompProfilePath: /usr/share/containers/seccomp.json
selinuxEnabled: false
serviceIsRemote: false
slirp4netns:
executable: /usr/bin/slirp4netns
package: slirp4netns_1.2.0-1_amd64
version: |-
slirp4netns version 1.2.0
commit: 656041d45cfca7a4176f6b7eed9e4fe6c11e8383
libslirp: 4.7.0
SLIRP_CONFIG_VERSION_MAX: 4
libseccomp: 2.5.4
swapFree: 0
swapTotal: 0
uptime: 0h 10m 36.00s
plugins:
authorization: null
log:
- k8s-file
- none
- passthrough
- journald
network:
- bridge
- macvlan
volume:
- local
registries: {}
store:
configFile: /etc/containers/storage.conf
containerStore:
number: 0
paused: 0
running: 0
stopped: 0
graphDriverName: overlay
graphOptions:
overlay.mount_program:
Executable: /usr/local/bin/overlayzfsmount
Package: Unknown
Version: 'mount from util-linux 2.38.1 (libmount 2.38.1: selinux, smack, btrfs,
verity, namespaces, assert, debug)'
overlay.mountopt: nodev
graphRoot: /var/lib/containers/storage
graphRootAllocated: 32212254720
graphRootUsed: 1242038272
graphStatus:
Backing Filesystem: zfs
Native Overlay Diff: "false"
Supports d_type: "true"
Using metacopy: "false"
imageCopyTmpDir: /var/tmp
imageStore:
number: 0
runRoot: /run/containers/storage
volumePath: /var/lib/containers/storage/volumes
version:
APIVersion: 4.3.1
Built: 0
BuiltTime: Thu Jan 1 00:00:00 1970
GitCommit: ""
GoVersion: go1.19.8
Os: linux
OsArch: linux/amd64
Version: 4.3.1

User has its subordinates defined

cockpit@Test:~$ grep cockpit /etc/subuid /etc/subgid
/etc/subuid:cockpit:165536:65536
/etc/subgid:cockpit:165536:65536

The same installation on VM works flawlessly, but on LXC I can't force it to work.

 

[marceliszpak]

when I look into lxc configuration file I see

root@proxmox:~# cat /etc/pve/lxc/106.conf
arch: amd64
cores: 2
features: nesting=1
hostname: Test
memory: 8192
net0: name=eth0,bridge=vmbr2,firewall=1,hwaddr=BC:24:11:49:21:6B,ip=dhcp,type=veth
ostype: debian
rootfs: local-zfs:subvol-106-disk-0,size=30G
swap: 512
unprivileged: 1
root@HomeServer:~#

Doesn't it lack lxc.idmap definition?

 

[completion]

I am encountering the same problem if the lxc is unprivileged.

But if the container is privileged, then rootless podman seems to work.

 

[marceliszpak]

I haven't tried, because it seems a little senseless in my opinion. In such a solution podman by itself and each container run on LXC root level can have root privileges on the host. I have found few topics where running unprivileged podman in unprivileged lxc container is not recommended or even discouraged because of nested isolation which doesn't work. For sure Proxmox doesn't support it.

So I gave up and run podman in light debian vm with Cockpit. Woks fine but consumes ca 0,5 GB RAM more.

 

[DHigginson]

I think it depends on your use case. For me, everything of value would already be inside the LXC. If it gets compromised, it doesn't make much difference that technically there's a host over it that's probably fine. To me the value of an LXC is easy backups and snapshots I can revert when testing changes. If it's either/or I'd rather have security handled at the Podman level. I haven't come across anything that suggests running a privileged LXC is WORSE than running packages like podman natively on the host, but it's not the easiest topic to research.