Also causing a lot of ELN tests to fail; seems like we have the SELinux troubleshooter installed on ELN GNOME whereas it's not in Workstation?

I see it on my rawhide test machine too. It's rather annoying, because it shows a popup notification every other second.

Proposing as an F45 Final blocker because this violates "There must be no SELinux denial notifications or crash notifications on boot of or during installation from a release-blocking live image, or at first login after a default install of a release-blocking desktop" on KDE (not on Workstation, as selinux GUI is not installed there).

*** Bug 2453108 has been marked as a duplicate of this bug. ***

*** Bug 2453273 has been marked as a duplicate of this bug. ***

> Since accountsservice-26.12.8-1.fc45 landed in Rawhide recently, I noticed a lot of new AVCs, all more or less the time (it seems to be constantly trying to do this thing and getting blocked):

The package passed tests because it was not considered critical or because there were no functional isues?

All the automated tests passed, see https://bodhi.fedoraproject.org/updates/FEDORA-2026-06f9bad997

> The package passed tests because it was not considered critical or because there were no functional isues?

Because it didn't cause any functional issues in any of the update tests, yeah. We don't have (neither in Fedora CI nor openQA) any formal 'this test causes new AVCs' check. There's a subtest in openQA which dumps out all the AVCs that happened during the test, which is run as part of *some* tests, but there's no diffing mechanism or anything.

This causes some of the openQA *compose* tests to fail, especially on ELN GNOME because selinux-troubleshoot is included in that build (it's not in Workstation), but as it happens, none of the tests that fail are in the subset of tests we run on updates. We run about 650 tests on each compose; the maximum subset of that currently run on updates is 170 tests (how many exactly get run depends which critpath groups the update is in). I do continually tweak and expand the subset, but there's obviously resource constraints to take into account (both the HW resources to run the tests, and the person hours to investigate and diagnose failures).

Ugh, also I just noticed the desktop_notifications_postinstall test on KDE is passing despite this problem...because the SELinux denial notification is shown separately from the main Notifications view, not as part of it:

https://openqa.fedoraproject.org/tests/4522800#step/desktop_notifications/31

I've just sent a fix for that - https://forge.fedoraproject.org/quality/os-autoinst-distri-fedora/commit/cf6ff0a2d0281bfcb6f3205ff1d4d230e75f6e1f - and I'll consider if we can add the desktop_notifications tests to the set run on updates.

I understand it is not possible nor reasonable to test everything. Especially if the package does not report a functional issue, certainly there is hardly any reason to gate the update. I suppose the failure is not critical and the service either has a workaround or just fanotify does not work and nobody cares, that's OK. If it had been reported in the journal, I expect somebody/something would have noticed the errors.

I'd like to point out though that the accountsservice package was updated and subsequently caused dozens of failing tests in other components (including selinux-policy - we started to see it with some delay) but not in itself. Unfortunately this is quite a common issue that a package has a substantial update from resource-using PoV and selinux-policy is not updated or even not notified to back the changes.

In RHEL tests, there is the no_avc_check option to deal with AVC denials. Is it possible in Fedora to have at least some follow-up actions like report the AVC denials which appeared in the test but were ignored if this was the case?

Possible, sure, do we have time for it? Not really, unfortunately. I don't usually look at the lists of AVCs encountered by tests anyway as I just don't have time, they mostly just sit there. It only bubbles up when it actually causes a functional test to fail (either because the AVC itself breaks something we test, or - as in this case - desktop notifications cause screenshot matching issues).

We *could* try and set a "there should be no AVCs caused by any of the gating openQA tests and any observed AVC is a gating failure" rule. That would actually be relatively simple to implement, technically speaking - certainly easier than some kind of informational diffing of *new* AVCs. The question is whether packagers would buy it as a rule.

> Unfortunately this is quite a common issue that a package has a substantial update from resource-using PoV and selinux-policy is not updated or even not notified to back the changes.

I'm not sure whether you meant it as a general information or anything about the way the update was done by me. I do not feel offended at all, that's perfectly fine, I only know I did not notice the problem before it was discovered by the QA folks. I updated more than 70 packages within the last two weeks. I'm not able to install each of them and verify whether it does not do anything wrong before I create an official update in Bodhi. While it can be considered as I'm lazy and I did the update process incorrectly, I'm also afraid "detecting" such new AVC-s (or any error) before the update is done without automation is not feasible. As least not for humans, due to time constraints. The automation cannot handle everything too (like the gdk-pixbuf2 update, which broke other semi-random apps, but for itself it was a clean & clear update).

(In reply to Milan Crha from comment #12)
> > Unfortunately this is quite a common issue that a package has a substantial update from resource-using PoV and selinux-policy is not updated or even not notified to back the changes.
> 
> I'm not sure whether you meant it as a general information or anything about
> the way the update was done by me. I do not feel offended at all, that's
> perfectly fine, I only know I did not notice the problem before it was
> discovered by the QA folks. I updated more than 70 packages within the last
> two weeks. I'm not able to install each of them and verify whether it does
> not do anything wrong before I create an official update in Bodhi. While it
> can be considered as I'm lazy and I did the update process incorrectly, I'm
> also afraid "detecting" such new AVC-s (or any error) before the update is
> done without automation is not feasible. As least not for humans, due to
> time constraints. The automation cannot handle everything too (like the
> gdk-pixbuf2 update, which broke other semi-random apps, but for itself it
> was a clean & clear update).

It was a general note, and at least this time it was reported quite quickly so it could have been addressed.
But I expect it is the maintainer's best interest that the package works properly.
For years, I've been trying to find a way out of situations like this as it can be really frustrating sometimes.

I understand that as long as the tests pass, the package goes live. I just want to say that the information (audit log, journal) is available, but often not processed to have any follow-up. From my point of view the best approach is to try to address the problems in advance although it is not always possible or e.g. it triggers only when some other package is installed or service running.

Right right, that makes sense. The accountsservice package is somehow different. I do not maintain it, I know basically nothing about it, I'm just updating it, because there was an upstream release and because I'm one of the folks from multiple teams whom circle in order to update gnome-sig packages. I did not expect any such disruption, the update seemed simple, but I've been clearly wrong.

The things can get even funnier with the Packit. Many gnome-sig packages are setup for it, for the stable branches only for now, then the "temporary maintainer" just merges a pull request at the fp.o/rpms/package web page and the rest is up to the Packit.

Some automation should step in, ideally. I'd be happy to help with the automation, but I've no idea what to do.

Unfortunately now we see a flood of read denials: https://bugzilla.redhat.com/show_bug.cgi?id=2456605