Description
Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)
/kind bug
Description
Running or creating containers from API is not consistent with creating them through the podman cli. Specifically, the PODMAN_USERNS environment variable for the podman system service is completely ignored and therefore you can't set a value as the default for that configuration.
The impact is for running rootless Podman + docker-compose, I can't have a similar experience as I would have with Docker + compose.
Steps to reproduce the issue:
-
Install docker-compose
-
Configure podman to run as rootless.
-
Start podman system service (through
systemctl enable --now --user podman.socket) -
Run
docker-compose run --rm testservice ls -lah /srvusing thedocker-compose.ymlbelow:services: testservice: image: docker.io/alpine:latest volumes: - ./:/srv
Describe the results you received:
You will see the list of files of your current directory as if they're owned by root. This is expected by a rootless container, however there's no way of turning it off, as you would have if you used this command:
podman run --userns=keep-id --rm -it -v "$(pwd):/srv" docker.io/alpine:latest ls -lah /srv
There's no support for setting userns in docker-compose to the value of keep-id, which is the option that allows us to disable the root mapping. I understand though, that this is a limitation of docker-compose and docker-py themselves (you can set userns_mode but only to the value of host, which is supported by Docker engine).
Describe the results you expected:
The implementation of userns (#3196) allowed us to set a global environment variable PODMAN_USERNS and then all containers created through podman run/create would have the userns set to the value of that variable. This does not happen, however, if you try to create the container through the Docker compose API. By using the API, you are required to send the HostConfig.UserNSMode parameter every time, so there's no concept of defaulting to env var. Therefore I couldn't even set that environment variable before running the server, because it will be ignored.
Output of podman version:
podman version 3.3.0
Output of podman info --debug:
host:
arch: amd64
buildahVersion: 1.22.3
cgroupControllers: []
cgroupManager: systemd
cgroupVersion: v2
conmon:
package: /usr/bin/conmon is owned by conmon 1:2.0.29-1
path: /usr/bin/conmon
version: 'conmon version 2.0.29, commit: 7e6de6678f6ed8a18661e1d5721b81ccee293b9b'
cpus: 12
distribution:
distribution: arch
version: unknown
eventLogger: journald
hostname: Arch-Home.lan
idMappings:
gidmap:
- container_id: 0
host_id: 1000
size: 1
- container_id: 1
host_id: 10000
size: 65536
uidmap:
- container_id: 0
host_id: 1000
size: 1
- container_id: 1
host_id: 10000
size: 65536
kernel: 5.10.60-1-lts
linkmode: dynamic
memFree: 9391316992
memTotal: 16670494720
ociRuntime:
name: crun
package: /usr/bin/crun is owned by crun 0.21-1
path: /usr/bin/crun
version: |-
crun version 0.21
commit: c4c3cdf2ce408ed44a9e027c618473e6485c635b
spec: 1.0.0
+SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +YAJL
os: linux
remoteSocket:
exists: true
path: /run/user/1000/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: true
seccompEnabled: true
seccompProfilePath: /etc/containers/seccomp.json
selinuxEnabled: false
serviceIsRemote: false
slirp4netns:
executable: /usr/bin/slirp4netns
package: /usr/bin/slirp4netns is owned by slirp4netns 1.1.12-1
version: |-
slirp4netns version 1.1.12
commit: 7a104a101aa3278a2152351a082a6df71f57c9a3
libslirp: 4.6.1
SLIRP_CONFIG_VERSION_MAX: 3
libseccomp: 2.5.1
swapFree: 0
swapTotal: 0
uptime: 27m 1.63s
registries: {}
store:
configFile: /home/dpereira/.config/containers/storage.conf
containerStore:
number: 1
paused: 0
running: 0
stopped: 1
graphDriverName: overlay
graphOptions:
overlay.mount_program:
Executable: /usr/bin/fuse-overlayfs
Package: /usr/bin/fuse-overlayfs is owned by fuse-overlayfs 1.7.1-1
Version: |-
fusermount3 version: 3.10.4
fuse-overlayfs: version 1.7.1
FUSE library version 3.10.4
using FUSE kernel interface version 7.31
graphRoot: /home/dpereira/.local/share/containers/storage
graphStatus:
Backing Filesystem: extfs
Native Overlay Diff: "false"
Supports d_type: "true"
Using metacopy: "false"
imageStore:
number: 27
runRoot: /run/user/1000/containers
volumePath: /home/dpereira/.local/share/containers/storage/volumes
version:
APIVersion: 3.3.0
Built: 1629546498
BuiltTime: Sat Aug 21 08:48:18 2021
GitCommit: 98f252a3a1a8f1ee00f9f96c6ba00500954b5093-dirty
GoVersion: go1.17
OsArch: linux/amd64
Version: 3.3.0
Package info (e.g. output of rpm -q podman or apt list podman):
❯ pacman -Qi podman
Name : podman
Version : 3.3.0-1
Description : Tool and library for running OCI-based containers in pods
Architecture : x86_64
URL : https://github.com/containers/podman
Licenses : Apache
Groups : None
Provides : None
Depends On : cni-plugins conmon containers-common device-mapper iptables libseccomp crun slirp4netns libsystemd fuse-overlayfs libgpgme.so=11-64
Optional Deps : podman-docker: for Docker-compatible CLI [installed]
btrfs-progs: support btrfs backend devices [installed]
catatonit: --init flag support
crun: support for unified cgroupsv2 [installed]
Required By : podman-docker
Optional For : None
Conflicts With : None
Replaces : None
Installed Size : 71.69 MiB
Packager : Morten Linderud <foxboron@archlinux.org>
Build Date : Sat 21 Aug 2021 08:48:18 AM -03
Install Date : Tue 24 Aug 2021 02:21:56 AM -03
Install Reason : Explicitly installed
Install Script : No
Validated By : Signature
Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide? (https://github.com/containers/podman/blob/master/troubleshooting.md)
Yes
Additional environment details (AWS, VirtualBox, physical, etc.):
I'm running it locally.