action #129961
closedpodman_netavark fails in SLE Micro 5.1 with SELinux enabled
100%
Description
The test fails when doing curl to port 80 of the apache container:
It only fails in this combination, in SLE Micro 5.3 for instance, this same thing works ok. Same for openSUSE MicroOS/TW.
The issue is when running the httpd container.
podman run --network simple:ip=10.90.0.8,mac=76:22:33:44:55:66 -d --name apache_ctr 3.71.98.16:5000/library/httpd
In normal cases, the container is started and you can curl and so, but in SLE Micro 5.1, after running this command, the container is stopped:
# podman run --network simple:ip=10.90.0.8,mac=76:22:33:44:55:66 -d --name apache_ctr 3.71.98.16:5000/library/httpd; echo SpNdV-$?-
Trying to pull 3.71.98.16:5000/library/httpd:latest...
Getting image source signatures
Copying blob 49d8a68fd903 [--------------------------------------] 0.0b / 299.0b (skipped: 0.0b = 0.00%)
...
WARN[0004] Path "/etc/SUSEConnect" from "/etc/containers/mounts.conf" doesn't exist, skipping
6377172b89981a3f0099260f7cf0c9e3e79c4a64ed45b19031e386681e61ae67
# podman container inspect apache_ctr --format {{.NetworkSettings.Networks.simple.IPAddress}}; echo 8M2l2-$?-
10.90.0.8
# podman ps --all
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
6377172b8998 3.71.98.16:5000/library/httpd:latest httpd-foreground 1 second ago Exited (1) Less than a second ago apache_ctr
Updated by jlausuch about 1 year ago
This seems a product bug. I have created https://bugzilla.suse.com/show_bug.cgi?id=1211774
Updated by jlausuch about 1 year ago
- Related to action #129910: New podman_netavark test fails everywhere in aarch64 and s390x added
Updated by jlausuch about 1 year ago
- Related to action #124631: Usage of netavark and aardvark in podman networks added
Updated by ph03nix about 1 year ago
- Status changed from Workable to In Progress
- Assignee set to ph03nix
Updated by ph03nix about 1 year ago
Reproducer¶
transactional-update pkg install netavark aardvark-dns
echo -e '[[registry]]\nlocation = "3.71.98.16:5000"\ninsecure = true' >> /etc/containers/registries.conf
echo -e '[Network]\nnetwork_backend="netavark"' > /etc/containers/containers.conf
podman system reset --force
podman network create --gateway 10.90.0.1 --subnet 10.90.0.0/16 simple
podman run --replace --network simple:ip=10.90.0.8,mac=76:22:33:44:55:66 -d --name apache_ctr 3.71.98.16:5000/library/httpd
podman container inspect apache_ctr --format {{.NetworkSettings.Networks.simple.IPAddress}}
curl --head --silent 10.90.0.8:80 # Change to IP from previous command
- Works on SLEM 5.4 with SELinux in enforcing mode
- Works on SLEM 5.1-5.3 with SELinux not being in enforcing
- Works on SLEM 5.3 with SELinux in enforcing mode
- SLEM 5.2 and SLEM 5.1 are affected by the issue
Updated by ph03nix about 1 year ago
From ausearch -m avc,user_avc,selinux_err -ts recent
# SLEM 5.2
time->Wed May 31 11:57:29 2023
type=AVC msg=audit(1685534249.909:90): avc: denied { open } for pid=1712 comm="httpd" path="pipe:[24234]" dev="pipefs" ino=24234 scontext=system_u:system_r:container_t:s0:c678,c822 tcontext=unconfined_u:system_r:container_runtime_t:s0-s0:c0.c1023 tclass=fifo_file permissive=0
# SLEM 5.1
time->Wed May 31 11:57:47 2023
type=AVC msg=audit(1685534267.530:88): avc: denied { open } for pid=1726 comm="httpd" path="pipe:[33360]" dev="pipefs" ino=33360 scontext=system_u:system_r:container_t:s0:c115,c897 tcontext=unconfined_u:system_r:container_runtime_t:s0-s0:c0.c1023 tclass=fifo_file permissive=0
This is likely a SELinux policy issue. Will file a bug for it.
Updated by jlausuch about 1 year ago
For now, we soft-fail the bug: https://progress.opensuse.org/issues/124631#note-18
Updated by ph03nix about 1 year ago
- Status changed from In Progress to Resolved
- % Done changed from 0 to 100
Filed: https://bugzilla.suse.com/show_bug.cgi?id=1211866. Replacing the label in the failing test runs.