obsolete

abrt-2.17.2-1.fc40, libreport-2.17.13-1.fc40, & 1 more

FEDORA-2024-82aa4e575f created by msrb 5 months ago for Fedora 40

This new release brings several bugfixes and improvements. Notably:

  • coredumps in the problem directory are kept compressed

This update's test gating status has been changed to 'waiting'.

5 months ago

This update's test gating status has been changed to 'failed'.

5 months ago

This update has been unpushed.

User Icon adamwill commented & provided feedback 5 months ago
karma

abrtd fails to start on boot because of SELinux denials, it seems:

Feb 05 14:39:14 fedora systemd[1]: Starting abrtd.service - ABRT Daemon...
Feb 05 14:39:14 fedora audit[729]: AVC avc:  denied  { nnp_transition } for  pid=729 comm="(abrtd)" scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:abrt_t:s0-s0:c0.c1023 tclass=process2 permissive=0
Feb 05 14:39:14 fedora audit: SELINUX_ERR op=security_bounded_transition seresult=denied oldcontext=system_u:system_r:init_t:s0 newcontext=system_u:system_r:abrt_t:s0-s0:c0.c1023
Feb 05 14:39:14 fedora audit[729]: AVC avc:  denied  { create } for  pid=729 comm="abrtd" name="abrtd.pid" scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:abrt_var_run_t:s0 tclass=file permissive=0
Feb 05 14:39:14 fedora abrtd[729]: Can't open '/var/run/abrt/abrtd.pid': Permission denied
Feb 05 14:39:14 fedora abrtd[729]: Error while initializing daemon

Yep, I noticed that too. That's why I quickly unpushed the update. I did not see the problem locally though, so I need to investigate more.

Hmm, I cannot reproduce the problem on a freshly installed up-to-date Rawhide VM.

This is interesting:

-   "ADVISORY" : "FEDORA-2024-617d585f1f",
-   "ADVISORY_NVRS_1" : "selinux-policy-40.11-1.fc40",
-   "ADVISORY_OR_TASK" : "FEDORA-2024-617d585f1f",
+   "ADVISORY" : "FEDORA-2024-82aa4e575f",
+   "ADVISORY_NVRS_1" : "abrt-2.17.2-1.fc40 libreport-2.17.13-1.fc40 satyr-0.43-1.fc40",
+   "ADVISORY_OR_TASK" : "FEDORA-2024-82aa4e575f",
-   "BUILD" : "Update-FEDORA-2024-617d585f1f",
+   "BUILD" : "Update-FEDORA-2024-82aa4e575f",

It seems like the new selinux-policy landed at the same time and was tested together with this update? I will try to re-push the update. The worst case scenario is that CI will keep the update blocked.

msrb edited this update.

5 months ago

msrb edited this update.

5 months ago

This update has been submitted for testing by msrb.

5 months ago

For the record, this is the test bug that I successfully created from the Rawhide VM: https://bugzilla.redhat.com/show_bug.cgi?id=2263025

Oh, wait. My freshly installed Rawhide VM is running in permissive mode by default? That's why I didn't see the problem...

It seems like the new selinux-policy landed at the same time and was tested together with this update?

No, that's not quite what it means. As it says on the left, that's a "diff_to_last_good" - it's showing you the diff between the openQA settings of the last test that passed before the failure, and those of the failed test. So it's showing you that it just so happens that the most recent pass was a test of an selinux-policy update.

The two were not tested together. openQA does not test pending updates together. How openQA works is that it configures the test system to use the official repositories for the relevant release, then adds a side repository which contains only the packages from the update under test.

For Rawhide update tests, it configures the main 'rawhide' repository and also a repo called 'koji-rawhide' which contains the packages from the current koji buildroot, so it includes packages that have been tagged since the previous nightly compose (I found this gives more reliable results and fewer false failures), so the test system will have all the packages tagged up to around when it started running, give or take, plus the packages from the update being tested. So this test may have included the selinux-policy update if it passed tests and was tagged before the tests for this update ran - I'm not sure, off the top of my head. But it's kinda academic, because again as "diff_to_last_good" implies, the test passed on the selinux-policy update. It also passed for all other updates before and since. It only failed for this update.

My freshly installed Rawhide VM is running in permissive mode by default?

I'm pretty sure that's not the case either. We actually do have a test of that in openQA, and it passed on all recent composes; it's called base_selinux, you can go to e.g. https://openqa.fedoraproject.org/tests/overview?distri=fedora&version=Rawhide&build=Fedora-Rawhide-20240206.n.0&groupid=1 and search for that string. We run the test on most of the images we test.

Thanks for the thorough explanation.

So, when it comes to selinux being in permissive mode by default, I tried again just now -- just to make sure that I wasn't dreaming. I don't know if this is expected or not, but these are my findings:

Fedora-Workstation-Live-osb-Rawhide-20240206.n.0.x86_64.iso -- this has the selinux policy set to permissive right after installation. I was doing the testing on this "osb" version, so maybe that's where I made the mistake?

Fedora-Workstation-Live-x86_64-Rawhide-20240206.n.0.iso -- this one indeed comes with selinux enforcing enabled by default.

This update's test gating status has been changed to 'waiting'.

5 months ago

This update's test gating status has been changed to 'failed'.

5 months ago

This update's test gating status has been changed to 'failed'.

5 months ago

This update's test gating status has been changed to 'failed'.

5 months ago

This update has been obsoleted.

5 months ago

Ah, I believe that's the experimental image built by osbuild - https://fedoraproject.org/wiki/Changes/FedoraWorkstationImageBuilder . We don't run that one through openQA yet, though we probably should, I just need to get around to implementing it. It's not the "Official" image yet, though. It would be worth reporting...somewhere...that it's not doing the right thing with SELinux, I guess.

The new selinux-policy build should address the issue: https://bodhi.fedoraproject.org/updates/FEDORA-2024-1ca4c99da3

Just to close the loop here -- I reported the issue with selinux and OSB images to the owners of the Fedora Image Builder change: https://fedoraproject.org/wiki/Changes/FedoraWorkstationImageBuilder

So they are aware of the issue and they will look into it ;)


Please login to add feedback.

Metadata
Type
enhancement
Severity
medium
Karma
-1
Signed
Content Type
RPM
Test Gating
Settings
Unstable by Karma
-3
Stable by Karma
3
Stable by Time
0 days
Dates
submitted
5 months ago
in testing
5 months ago
modified
5 months ago

Automated Test Results

Test Cases

0 0 Test Case ABRT Application restart
0 0 Test Case ABRT BlackList
0 0 Test Case ABRT Bugzilla plugin
0 0 Test Case ABRT CCPP addon
0 0 Test Case ABRT CLI
0 0 Test Case ABRT CLI Localized
0 0 Test Case ABRT Configuration Storage
0 0 Test Case ABRT Cron
0 0 Test Case ABRT Desktop auto-reporting
0 0 Test Case ABRT GPG Keys
0 0 Test Case ABRT GPG check
0 0 Test Case ABRT GUI Localized
0 0 Test Case ABRT GUI MAIN
0 0 Test Case ABRT GUI Translation
0 0 Test Case ABRT Logger plugin
0 0 Test Case ABRT Mailx plugin
0 0 Test Case ABRT Plugins
0 0 Test Case ABRT RemoveSecurityInformation
0 0 Test Case ABRT Reporting Known Crash
0 0 Test Case ABRT SELinux
0 0 Test Case ABRT ccpp-journal
0 0 Test Case ABRT cnotify
0 0 Test Case ABRT containers
0 0 Test Case ABRT kernel addon
0 0 Test Case ABRT kernel-journal
0 0 Test Case ABRT python addon
0 0 Test Case ABRT python better debugging
0 0 Test Case ABRT python3
0 0 Test Case ABRT quota
0 0 Test Case ABRT ruby gem
0 0 Test Case ABRT server
0 0 Test Case ABRT sosreport
0 0 Test Case ABRT third party event extension
0 0 Test Case ABRT vmcore
0 0 Test Case ABRT vmcores
0 0 Test Case GNOME ABRT MAIN
0 0 Test Case Libreport Anaconda Install
0 0 Test Case Libreport anaconda
0 0 Test Case Libreport firstboot
0 0 Test Case Libreport sealert
0 0 Test Case Retrace Server CLI
0 0 Test Case Retrace Server GUI