Bug 1889521

Summary: gdm won't log in after selinux policy change in upgrade
Product: [Fedora] Fedora Reporter: George White <me>
Component: selinux-policyAssignee: Zdenek Pytela <zpytela>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: dwalsh, grepl.miroslav, lvrabec, mmalik, plautrba, vmojzis, zpytela
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-10-20 07:00:58 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Output of `ausearch -c gdm-session-wor` none

Description George White 2020-10-19 20:31:46 UTC
Created attachment 1722702 [details]
Output of `ausearch -c gdm-session-wor`

Description of problem:
After running dnf upgrade, gdm would no longer log in any user for any session. Audit messages are printed to the journal which show gdm is being denied access to its own scripts.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Power on machine.
2. Boot to gdm.
3. Attempt to log in to either GNOME, GNOME Classic, GNOME on Xorg session types with a valid user and password combination.

Actual results:
gdm returns the user to the user selection screen

Expected results:
The GNOME desktop starts.

Additional info:
Attached is the output of `ausearch -c gdm-session-wor`.

Comment 1 George White 2020-10-19 20:34:00 UTC
Passing these audit messages to audit2allow, then adding the allow stanzas to the system policy resolves the issue.

Comment 2 Zdenek Pytela 2020-10-20 07:00:58 UTC

*** This bug has been marked as a duplicate of bug 1886196 ***