#447 Many fedora-ci.koji-build.installability.functional tests fail, maybe because of an SELinux AVC denial for mandb
Opened 7 months ago by ppisar. Modified 24 days ago

I notice that many fedora-ci.koji-build.installability.functional tests fail like in https://artifacts.dev.testing-farm.io/81fa0d39-cb75-4099-90c1-ad7c0706b0dc/:100:

Set selinux enforce to: 1
[...]
Complete!
Selinux policy:
----
type=AVC msg=audit(11/22/2023 09:10:13.155:1088) : avc:  denied  { map_read map_write } for  pid=10733 comm=mandb scontext=system_u:system_r:mandb_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=bpf permissive=0 
Shared connection to 3.138.156.29 closed.

The logs do not mention any failure except the AVC. Probably when running mandb from an RPM file trigger which attempts to access an init script? I cannot reproduce it locally.


@ppisar thanks for filing, this is unfortunately a known issue caused by a systemd update I believe. More info on internal Slack and in following bugzillas:

https://redhat-internal.slack.com/archives/C04L304KVH9/p1700674280153949?thread_ts=1700656735.656049&cid=C04L304KVH9

https://bugzilla.redhat.com/show_bug.cgi?id=2250930
https://bugzilla.redhat.com/show_bug.cgi?id=2250935

Trying to talk to @zbyszek if we could start gating systemd on installability, which clearly shown the problem:

https://bodhi.fedoraproject.org/updates/FEDORA-2023-f631207330

The tests always fail. I tried to fix them, but there are very little docs, and the docs that are there are (at least for me) just incomprehensible. I asked in various places (e.g. https://pagure.io/fedora-project-config/issue/292), but that never went anywhere.

But if you can make the tests return useful results, I would be happy to look at them in the future.

It would also help a lot if the journal was saved. Ideally, as a standalone file produced by systemd-journal-remote. Having the messages in context and with metadata, and not just the console output, would it easier to diagnose failures.

Metadata Update from @mvadkert:
- Issue status updated to: Closed (was: Open)

7 months ago

I added the suggestion about saving journal there ...

Metadata Update from @mvadkert:
- Issue status updated to: Open (was: Closed)

7 months ago

Reopening, the systemd problem still persists

So it looks like Anaconda packages are now affected by this:

BAD
install: anaconda-0:41.17-1.fc41.x86_64 (selinux AVCs)


type=AVC msg=audit(05/21/2024 10:36:13.721:725) : avc: denied { map_read map_write } for pid=3937 comm=selinux-autorel scontext=system_u:system_r:selinux_autorelabel_generator_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=bpf permissive=0

type=AVC msg=audit(05/21/2024 10:36:13.730:726) : avc: denied { map_read map_write } for pid=3941 comm=systemd-fstab-g scontext=system_u:system_r:systemd_fstab_generator_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=bpf permissive=0

type=AVC msg=audit(05/21/2024 10:36:13.736:727) : avc: denied { map_read map_write } for pid=3948 comm=systemd-rc-loca scontext=system_u:system_r:systemd_rc_local_generator_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=bpf permissive=0

type=AVC msg=audit(05/21/2024 10:36:13.737:728) : avc: denied { map_read map_write } for pid=3943 comm=systemd-gpt-aut scontext=system_u:system_r:systemd_gpt_generator_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=bpf permissive=0

type=AVC msg=audit(05/21/2024 10:36:13.744:729) : avc: denied { map_read map_write } for pid=3953 comm=systemd-sysv-ge scontext=system_u:system_r:systemd_sysv_generator_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=bpf permissive=0

type=AVC msg=audit(05/21/2024 10:36:13.775:730) : avc: denied { read } for pid=3950 comm=systemd-ssh-gen name=vsock dev="devtmpfs" ino=386 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:vsock_device_t:s0 tclass=chr_file permissive=0
BAD
install: anaconda-core-0:41.17-1.fc41.x86_64 (selinux AVCs)


type=AVC msg=audit(05/21/2024 10:36:35.758:1348) : avc: denied { map_read map_write } for pid=4789 comm=selinux-autorel scontext=system_u:system_r:selinux_autorelabel_generator_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=bpf permissive=0

type=AVC msg=audit(05/21/2024 10:36:35.761:1349) : avc: denied { map_read map_write } for pid=4793 comm=systemd-fstab-g scontext=system_u:system_r:systemd_fstab_generator_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=bpf permissive=0

type=AVC msg=audit(05/21/2024 10:36:35.772:1350) : avc: denied { map_read map_write } for pid=4795 comm=systemd-gpt-aut scontext=system_u:system_r:systemd_gpt_generator_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=bpf permissive=0

type=AVC msg=audit(05/21/2024 10:36:35.784:1351) : avc: denied { map_read map_write } for pid=4801 comm=systemd-rc-loca scontext=system_u:system_r:systemd_rc_local_generator_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=bpf permissive=0

type=AVC msg=audit(05/21/2024 10:36:35.821:1352) : avc: denied { map_read map_write } for pid=4806 comm=systemd-sysv-ge scontext=system_u:system_r:systemd_sysv_generator_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=bpf permissive=0

type=AVC msg=audit(05/21/2024 10:36:35.832:1353) : avc: denied { read } for pid=4803 comm=systemd-ssh-gen name=vsock dev="devtmpfs" ino=386 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:vsock_device_t:s0 tclass=chr_file permissive=0

And similar: https://artifacts.dev.testing-farm.io/6bf474f1-56c9-4c1a-8f32-928023cdf205/ for https://src.fedoraproject.org/rpms/anaconda/pull-request/158#

We looked into this yesterday with jpopelka, but were not able to determine what is causing it.

Interesting enough, this really seems like an infra or test issues, rather than something specific to a new Anaconda version, as it passed for the 41.15 Anaconda currently in repos in the past.

But when I tried to trigger a test run using the 41.15 spec file and tarball, I got the same test failure:

https://src.fedoraproject.org/rpms/anaconda/pull-request/159
https://artifacts.dev.testing-farm.io/dbca7c0a-83dc-4214-ab15-fd136b03a5e8/

Log in to comment on this ticket.

Metadata