Bug 1577498

Summary:	systemd-logind restart code is broken somewhere (I'm not sure if it's fixed upstream yet or not)
Product:	[Fedora] Fedora	Reporter:	Alan Jenkins <alan.christopher.jenkins>
Component:	selinux-policy	Assignee:	Lukas Vrabec <lvrabec>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	28	CC:	dwalsh, lvrabec, mgrepl, plautrba, pmoore
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2018-05-12 18:51:14 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:

Description Alan Jenkins 2018-05-12 13:19:38 UTC

Description of problem:
SELinux enforcement is blocking the systemd code which would handle logind restart.

This is not urgent in itself, because no-one relies on the logind restart code.

Version-Release number of selected component (if applicable):
selinux-policy-targeted-3.14.1-24.fc28.noarch

How reproducible: as below

Steps to Reproduce:
1. Fedora Workstation 28
2. Boot
3. Log in to GNOME
4. In a terminal, run

sudo lsof -p 1 | grep dri

Actual results:

/dev/dri/card0 is shown as being open in PID 1. This is a copy of the FD which logind has granted to gnome-shell. logind must keep this *exact* FD, in order that logind can force switches between sessions / VTs even when a session becomes non-responsive.

But there is only *one* such FD shown...

Expected results:

In fact, there should be two such FDs shown. Logging in to GNOME on Fedora, leaves gdm running on tty1, while gnome-shell runs on tty2.

Additional info:

This appears to be a regression from Fedora 27.

Additionally, the "expected results" can be obtained by booting with `enforcing=0`. However nothing appears in "Selinux Troubleshooter", and there seems to be nothing relevant in the audit log. So it is a "dontaudit" rule or something more subtle.

---

Context: I am having some unexpected behaviour with memory/swap usage. I seem to be filling up memory quite quickly, just from starting a single VM. I have 8GB RAM, and the VM is allocated 1.75GB. I found this strange behaviour with the DRI FDs because I started investigating whether my memory usage problem was related to the Fedora 27 bug described here:

https://unix.stackexchange.com/questions/431982/what-could-be-using-6gb-of-my-swap

Comment 1 Alan Jenkins 2018-05-12 13:30:50 UTC

Sorry, I wasn't clear.  logind needs to keep these FDs, and it's supposed to keep them even if it's restarted.  The ways this feature works is that when the FD is created, it is also sent to systemd for safe-keeping.  (See `man sd_pid_notify_with_fds`.  This is also referred to as FDSTORE).

Looking at the `lsof` results it looks as if the initial FD passing to PID 1 works ok, but then when we switch sessions, the FD gets dropped for some reason.

You can see this, in that if you subsequently press ctrl+alt+f6 and log in on the text console, then running the `lsof` command will show that PID 1 has *no* open FDs for /dev/dri/card0.

Comment 2 Alan Jenkins 2018-05-12 13:37:17 UTC

Note if you then switch back to GNOME on tty2, the FD does not re-appear in PID 1.  PID 1 is left with zero FDs of /dev/dri/card0.

Comment 3 Alan Jenkins 2018-05-12 18:51:14 UTC

Gah. This is not a SELinux bug. I am having the same sort of problem on my laptop both with and without `enforcing=0`.

Partly it is awkward to reproduce, because of a systemd bug where unplugging an input device (e.g. mouse) causes logind to remove *all* the device FDs from PID 1.  So don't unplug your mouse from your laptop while testing this...

But more importantly, you have to watch out for the same side-issue on VMs, because they hotplug some magic tablet/touchscreen device at weird times. I think on VT switch, for example.  I think the way to test this on a VM without such interference, is to run `systemctl mask spice-vdagentd.serivce` (and reboot) inside the VM.

The side-issue is fixed in the next release of systemd (v239). https://github.com/systemd/systemd/issues/8344

Then I'm still getting a different result between VM and the laptop itself.  On the laptop, after logging in to GNOME, PID 1 has one FDs of /dev/dri/card0.  Inside the F28 VM, after logging in to GNOME, PID 1 has zero FDs of /dev/dri/card0.

Only if I go back to the F27 VM, can I see the desired result of two FDs of /dev/dri/card0 in PID 1.