common: podman does not adhere to path set with LIBEXECDIR (e.g. for catatonit)
Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)
/kind bug
Description
Podman only accepts executables in /usr/libexec/podman (even if LIBEXECDIR is set to something else). This conflicts with OSes, that do not use /usr/libexec (e.g. Arch Linux) and package catatonit in /usr/lib/podman/catatonit.
Steps to reproduce the issue:
-
make EXTRA_LDFLAGS='-s -w -linkmode=external' -C $pkgbase&make install install.completions DESTDIR="$pkgdir" PREFIX=/usr LIBEXECDIR=/usr/lib -C $pkgbase(or install podman 4.1.1-2 on Arch Linux, which pulls in catatonit symlinked to /usr/lib/podman/catatonit) -
Run
podman run --init docker.io/library/busybox
Describe the results you received:
"Error: container-init binary not found on the host: stat /usr/libexec/podman/catatonit: no such file or directory"
(see downstream bug report https://bugs.archlinux.org/task/75493)
Describe the results you expected:
Podman’s build system can be configured with LIBEXECDIR and podman afterwards adheres to that configured directory.
Additional information you deem important (e.g. issue happens only occasionally):
Output of podman version:
Client: Podman Engine
Version: 4.1.1
API Version: 4.1.1
Go Version: go1.18.3
Git Commit: f73d8f8875c2be7cd2049094c29aff90b1150241
Built: Fri Jun 24 09:33:56 2022
OS/Arch: linux/amd64
Output of podman info --debug:
host:
arch: amd64
buildahVersion: 1.26.1
cgroupControllers:
- memory
- pids
cgroupManager: systemd
cgroupVersion: v2
conmon:
package: /usr/bin/conmon is owned by conmon 1:2.1.3-1
path: /usr/bin/conmon
version: 'conmon version 2.1.3, commit: ab52a597278b20173440140cd810dc9fa8785c93'
cpuUtilization:
idlePercent: 99.04
systemPercent: 0.41
userPercent: 0.55
cpus: 24
distribution:
distribution: arch
version: unknown
eventLogger: journald
hostname: hmbx
idMappings:
gidmap:
- container_id: 0
host_id: 1000
size: 1
- container_id: 1
host_id: 165536
size: 4096
uidmap:
- container_id: 0
host_id: 1000
size: 1
- container_id: 1
host_id: 165536
size: 4096
kernel: 5.18.12-hardened1-1-hardened
linkmode: dynamic
logDriver: journald
memFree: 1003122688
memTotal: 67342626816
networkBackend: netavark
ociRuntime:
name: crun
package: /usr/bin/crun is owned by crun 1.5-1
path: /usr/bin/crun
version: |-
crun version 1.5
commit: 54ebb8ca8bf7e6ddae2eb919f5b82d1d96863dea
spec: 1.0.0
+SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +YAJL
os: linux
remoteSocket:
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.2.0-1
version: |-
slirp4netns version 1.2.0
commit: 656041d45cfca7a4176f6b7eed9e4fe6c11e8383
libslirp: 4.7.0
SLIRP_CONFIG_VERSION_MAX: 4
libseccomp: 2.5.4
swapFree: 21712936960
swapTotal: 22447202304
uptime: 312h 9m 12.15s (Approximately 13.00 days)
plugins:
log:
- k8s-file
- none
- passthrough
- journald
network:
- bridge
- macvlan
volume:
- local
registries:
search:
- docker.io
store:
configFile: /home/dave/.config/containers/storage.conf
containerStore:
number: 3
paused: 0
running: 0
stopped: 3
graphDriverName: btrfs
graphOptions: {}
graphRoot: /home/dave/.local/share/containers/storage
graphRootAllocated: 999662751744
graphRootUsed: 615612772352
graphStatus:
Build Version: Btrfs v5.18.1
Library Version: "102"
imageCopyTmpDir: /run/user/1000
imageStore:
number: 1
runRoot: /run/user/1000/containers
volumePath: /home/dave/.local/share/containers/storage/volumes
version:
APIVersion: 4.1.1
Built: 1656056036
BuiltTime: Fri Jun 24 09:33:56 2022
GitCommit: f73d8f8875c2be7cd2049094c29aff90b1150241
GoVersion: go1.18.3
Os: linux
OsArch: linux/amd64
Version: 4.1.1
Package info (e.g. output of rpm -q podman or apt list podman):
Name : podman
Version : 4.1.1-2
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 : catatonit conmon containers-common crun iptables libdevmapper.so=1.02-64 libgpgme.so=11-64 libseccomp.so=2-64 slirp4netns
Optional Deps : apparmor: for AppArmor support [installed]
btrfs-progs: support btrfs backend devices [installed]
netavark: for a new container-network-stack implementation [installed]
podman-compose: for docker-compose compatibility [installed]
podman-docker: for Docker-compatible CLI
Required By : cockpit-podman podman-compose
Optional For : python-pytest-testinfra
Conflicts With : None
Replaces : None
Installed Size : 63.27 MiB
Packager : David Runge <dvzrv@archlinux.org>
Build Date : 2022-06-24T09:33:56 CEST
Install Date : 2022-06-24T09:38:16 CEST
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/main/troubleshooting.md)
Yes (not relevant for this ticket)
Additional environment details (AWS, VirtualBox, physical, etc.):
Locations in which hardcoding in the codebase takes place: https://github.com/containers/podman/blob/c09457e34a429622475e27fe68e17effe47fe0c3/pkg/rootless/rootless_linux.c#L137 https://github.com/containers/podman/blob/c09457e34a429622475e27fe68e17effe47fe0c3/test/e2e/run_test.go#L319
Locations in containers/common that hardcode /usr/libexec/podman: https://github.com/containers/common/blob/ab553b9c2292b29d34400867a83d5df571be9080/pkg/config/containers.conf#L149 https://github.com/containers/common/blob/ab553b9c2292b29d34400867a83d5df571be9080/pkg/config/containers.conf#L360 https://github.com/containers/common/blob/ab553b9c2292b29d34400867a83d5df571be9080/pkg/config/default.go#L53
There are probably more, but it’s hard to estimate with the components being a bit of a moving target.
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Comments: 17 (11 by maintainers)
Commits related to this issue
- default: look up init binary in helper_binaries_dir Some Linux distributions does not install files into `/usr/libexec` and would fail to lookup the init binary. This change first checks if the file... — committed to Foxboron/common by Foxboron 2 years ago
- pkg/config: lookup InitPath in HelperBinariesDir Forcing a single upstream default for the init path is bad as some distro use differnt install locations for various reasons. To fix this use the exi... — committed to Luap99/common by Luap99 8 months ago
- pkg/config: lookup InitPath in HelperBinariesDir Forcing a single upstream default for the init path is bad as some distro use different install locations for various reasons. To fix this use the ex... — committed to Luap99/common by Luap99 8 months ago
- use FindInitBinary() for init binary Use the new FindInitBinary() function to lookup the init binary, this allows the use of helper_binaries_dir in contianers.conf[1] [NO NEW TESTS NEEDED] [1] http... — committed to Luap99/libpod by Luap99 8 months ago
- use FindInitBinary() for init binary Use the new FindInitBinary() function to lookup the init binary, this allows the use of helper_binaries_dir in contianers.conf[1] [NO NEW TESTS NEEDED] [1] http... — committed to Luap99/libpod by Luap99 8 months ago
- pkg/config: lookup InitPath in HelperBinariesDir Forcing a single upstream default for the init path is bad as some distro use different install locations for various reasons. To fix this use the ex... — committed to Luap99/common by Luap99 8 months ago
- use FindInitBinary() for init binary Use the new FindInitBinary() function to lookup the init binary, this allows the use of helper_binaries_dir in contianers.conf[1] [NO NEW TESTS NEEDED] [1] http... — committed to Luap99/libpod by Luap99 8 months ago
- use FindInitBinary() for init binary Use the new FindInitBinary() function to lookup the init binary, this allows the use of helper_binaries_dir in contianers.conf[1] [NO NEW TESTS NEEDED] [1] http... — committed to Luap99/libpod by Luap99 8 months ago
IMO there is no reason to only use one path for the init binary. We already have the helper_binaries_dir field to specify a list of directories. I think we should look there as well.