Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at
Bug 1513832 - SELINUX Confined user (staff_t) cannot log in via GDM
Summary: SELINUX Confined user (staff_t) cannot log in via GDM
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 27
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Lukas Vrabec
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2017-11-16 04:44 UTC by Chris Smith
Modified: 2017-11-20 16:56 UTC (History)
5 users (show)

Fixed In Version: selinux-policy-3.13.1-283.16.fc27
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2017-11-20 16:56:41 UTC
Type: ---

Attachments (Terms of Use)

Description Chris Smith 2017-11-16 04:44:26 UTC
User-Agent:       Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0
Build Identifier: 

After updating my Fedora 27 install to latest patch level from mirrors, I found that I couldn't log in to the desktop via GDM any longer.

The only AVC I could see indicated that it could be related to a gnome keyring problem. After patching the policy to allow for the logged action, it was found to be still failing.

GDM login worked fine when "setenforce 0" so was obviously an SELINUX issue.

Some further investigation (including disabling all dontaudit's in my policy) indicated some issues around init_t, init_exec_t and staff_t. "semanage permissive -a init_t" allowed everything to work fine.

Addressing and patching the init_t AVC's did not fix the problem, but addressing the init_exec_t AVC did. Here is an example AVC (usually squashed by a dontaudit):

time->Thu Nov 16 16:45:52 2017
type=AVC msg=audit(1510803952.496:325): avc:  denied  { map } for  pid=5491 comm="systemd" path="/usr/lib/systemd/systemd" dev="dm-1" ino=2240297 scontext=staff_u:staff_r:staff_t:s0-s0:c0.c1023 tcontext=system_u:object_r:init_exec_t:s0 tclass=file permissive=0

Running this through audit2allow generated the following policy module:

module my-systemd-fix 1.0;

require {
	type staff_t;
	type init_exec_t;
	class file map;

#============= staff_t ==============

#!!!! This avc has a dontaudit rule in the current policy
allow staff_t init_exec_t:file map;

Loading this module appears to have fixed the issue and login now works again.

Please forgive my bumbling as I am relatively new to selinux and am still learning how to drive it.

Reproducible: Always

Steps to Reproduce:
1. Install a fresh F27, apply all updates
2. Create a user
3. Attempt to login via GDM - observe login success
4. usermod -Z staff_u username
5. Attempt to login via GDM 
Actual Results:  
Login fails, black screen shown and returned to login screen.

Additionally, the systemd user service fails to start.

Expected Results:  
Login success, and systemd user service starts

Comment 1 Fedora Update System 2017-11-16 15:12:21 UTC
selinux-policy-3.13.1-283.16.fc27 has been submitted as an update to Fedora 27.

Comment 2 Fedora Update System 2017-11-17 18:56:22 UTC
selinux-policy-3.13.1-283.16.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report.
See for
instructions on how to install test updates.
You can provide feedback for this update here:

Comment 3 Fedora Update System 2017-11-20 16:56:41 UTC
selinux-policy-3.13.1-283.16.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.