--- Running analyze_BodhiUpdates ---
Looking for similar problems in bugzilla
abrt-action-find-bodhi-update [WARNING] Duplicate Bugzilla bug '#2327878' was found
Searching for updates
No updates for this package found
--- Running report_Bugzilla ---
Checking for duplicates
Creating a new bug...
Failed to create bug.
Server says: 404 Not Found
{"code":51,"error":true,"message":"There is no component named 'None' in the 'Fedora' product.","documentation":"https://bugzilla.redhat.com/docs/en/html/api/index.html"}
('report_Bugzilla' exited with 1)
Remediation
Using the “Repeat” button, I don’t see anywhere in the GUI where I can override this, but want to file the report. (If someone could at least temporarily create the None component inside Fedora, that’d be useful!)
Additionally, I presume that this is a bug. However, would I file it at Red Hat’s Bugzilla instance, or the relevant GitHub repository’s issue tracker? I presume the former, but would appreciate confirmation.
First, I think this is already tackled by BZ#2328030, but it was shifted to selinux-policy, and a lot is open there, so a minor case as this might be not highest priority, and my own data is relevant only partly as my defaults are different to current Fedora defaults. Yet, you are free to add your data there about how the denial is caused in your case.
Second, removing any component is not useful: the component determines who gets informed and who is responsible. If no component would be selected, no one would get anything about the ticket, nor is it likely that anyone would feel responsible. Thus, it would be a waste of your time and of ticket numbers as likely no one would do anything about it nor become aware of it
Concerning components, you might check out what is related and choose the component that is superordinated. Here, the logical choice would lead you to either a VM component or selinux-policies. In case of a doubt about SELinux policies (=denials), just choose selinux-policy. That’s better than no report, and this component is responsible for most policy issues/adjustments anyway. But in your case, I would just add your data to the existing ticket rather than creating a new one (if applicable, Zdenek of selinux-policy will then identify your issue as new and subsequently ask you to create a new one)
I have never used that GUI to make an (automated?) report, but if something is not right about it, you might write a bug report about that GUI itself. However, I could imagine that the GUI cannot automatically identify a component, and “None” makes no sense (so rejecing “None” is not a bug!) - as mentioned, in case of a doubt with selinux policy issues, choose “selinux-policy” as component. So off the cuff I see no bug in the troubleshooter (although I am not 100% sure if I understand what you attempted).
Hope that helps a little
other question, does the denial go along with any issues/problems in your case? Or do you have any VM-related issues before or after the denial (even if hours are in between)? I tend to assume that it does not cause problems at the moment and thus is not worth a high priority anyway (I have a major VM issue atm but I assume so far that it is not related to the denial)
@py0xc3, not that I know of. I report these regardless because, thus far, every SELinux denial I’ve reported has been an issue (since every one has eventually become RESOLVED with FIXED or, occasionally, DUPLICATE).
The “Fedora” project is comprised of a component for every package exposed via the official repositories. Consequently, the wizard should be unable to target “None”, because there should always be a component assigned to a package.
I don’t believe that Bugzilla supports componentless tickets, even Harmony or Mozilla’s advanced downstream. Though, why do you mention this? I don’t see immediate context.
Indeed, I do not question this I just wanted to find out if there are cases in which this specific case causes trouble. You should always report, but if no issue is there, the priority might be low compared to issues that cause issues
I think there is a misunderstanding here: My perception was that you wanted to file a ticke twithout any component (None), which does not make sense because a component is necessary to make anyone responsible/aware of it. As you said, everything has assigned a component, and if any GUI is not able to identify it, it still is. Therefore, if you have no means to identify the component of an SE denial, use in case of a doubt the component selinux-policy.
Although I now presume that you know that already, a component name is not always equal to the package related to the denial.
The problem is that the “obvious denial data” does not necessarily tell you for sure where an adjustment is necessary. This is why much of selinux policies have been centralized in selinux-policy. There is also a repo on github to tackle some se-specific issues, but when it comes to report unintended denials, a normal bugzilla ticket should be used as that allows easier collaboration and involvement of other teams, due to the implications that are possible. I am not convinced that automatically and reliably identifying responsible components for each unintended SE denial works out, especially as I am not sure if that would sometimes end up at teams/packager without much knowledge about the SE organization, and thus not knowing what component to transfer it to.
That said, if I get it now right the issue you experience (you did not want to target None but the GUI chooes it, without allowing you to change that), you might open a ticket that in case of a doubt, None is replaced by selinux-policy. Cannot help much more with the GUI as I never used it for that.
@py0xc3, in retrospect, I agree. Ideally, it would apply an selinux tag to all issues reported by it. I’ve been disappointed by how underutilised tags are in RHBZ – gnome-abrt, for comparison, merely prefixes the titles with [abrt].
Doesn’t dnf5 provides always work? (I usually run that, and then an rpm -qa to ensure that the package referenced exists on the local installation. sealert should be capable of that.)
The problem is related to the selinux-policies, their implications and outreach. E.g., you cannot say for sure at each denial which policy is the origin of the problem (not of the denial, its not always as obvious as it looks). The implications can be very complex and far reaching. The implications among packages and policies (and interactions/impacts between different packages and different policies, including impacts of policy of package A on package B), including policy impacts on/between packages that depend on each other and so on. Especially virtualization is a complex case. In short, we do not create one policy for one package and then this policy impacts only this package and vice versa
However, the general selinux tag you seek is effectively selinux-policy, and if a default is set, it should be this one. And if they are not responsible for a selinux policy, they will know who is.
Cannot say much about the GUIs, nor if the origin of the problem is us or any upstream community such as GNOME.
@py0xc3, considering that it appears to be a misconfiguration in the RHBZ integration, I’ll presume that it’s ours. Consequently, I’ve filed bugzilla.redhat.com/show_bug.cgi?id=2373185, with a recommendation that the default be set to selinux-policy, as you’ve described:
SEAlert attempts to submit a report to a 404 RHBZ product.
Description of problem:
I am unable to submit one SEAlert report, due to a non-existent product in RHBZ.
Version-Release number of selected component (if applicable):
On the report in question, 100%. On none else, thus far. It’s report-dependent.
Steps to Reproduce:
Invoke sealert’s GUI.
Submit a report of an incident.
Actual results:
abrt-action-find-bodhi-update [WARNING] Duplicate Bugzilla bug '#2327878' was found
Searching for updates
No updates for this package found
--- Running report_Bugzilla ---
Checking for duplicates
Creating a new bug...
Failed to create bug.
Server says: 404 Not Found
{"code":51,"error":true,"message":"There is no component named 'None' in the 'Fedora' product.","documentation":"https://bugzilla.redhat.com/docs/en/html/api/index.html"}
('report_Bugzilla' exited with 1)
Expected results:
It should submit, to at least selinux-policy as a fallback.
I just wanted to find out if there are cases in which this specific case causes trouble. You should always report, but if no issue is there, the priority might be low compared to issues that cause issues 