Bug 1473806
Summary: | User cannot log in: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: No display available | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Ian Collier <imc> | ||||
Component: | freeipa | Assignee: | IPA Maintainers <ipa-maint> | ||||
Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | high | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | 26 | CC: | abokovoy, ipa-maint, jcholast, jhrozek, pvoborni, rcritten, rstrode, ssorce, tkrizek | ||||
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: | 2017-08-14 08:56:52 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
Ian Collier
2017-07-21 17:39:00 UTC
I am currently reproducing this on a fresh F26 install on a VM. However, there appear to be two different issues: 1. Unable to register display with display manager 2. (as noted above) Cannot open virtual console The latter message seems to happen if a login is attempted shortly after the previous login failed, and therefore I think it is a recurrence of Bug 1263208. This may or may not have anything to do with the fact that gnome-keyring-daemon processes owned by the user seem to get left running. But ironically this may also be what helps the user log in after switching VT. Message 1 only seems to affect networked users; a local user can log in straight away when the machine is booted. Message 2 affects both local and networked users. This appears to be what's causing the "Unable to register display" message: method call time=1501682517.473966 sender=:1.70 -> destination=:1.19 serial=5 path=/org/gnome/DisplayManager/Manager; interface=org.gnome.DisplayManager.Manager; member=RegisterDisplay array [ dict entry( string "session-type" string "x11" ) dict entry( string "x11-display-name" string ":0" ) ] error time=1501682517.474734 sender=:1.19 -> destination=:1.70 error_name=org.freedesktop.DBus.Error.AccessDenied reply_serial=5 string "No display available" This happens: - using GDM on Wayland while requesting a GNOME/Xorg session - using GDM on Wayland while requesting a GNOME/Wayland session - using GDM on Xorg while requesting a GNOME/Xorg session (it doesn't seem to be possible to request a GNOME/Wayland session using GDM on Xorg.) Created attachment 1308407 [details]
Debug log of a login failure
I'm attaching a debug log showing what GDM does when the login fails.
I believe the cause might be this:
GdmDisplay: session id:
(that is, no session id is printed).
> 1. systemd: user: Failed at step PAM spawning
> /usr/lib/systemd/systemd: Operation not permitted
I guess this is probably the first failure that leads to the other failures.
looking in /lib/systemd/system/user@.service I see:
PAMName=systemd-user
Looking in /etc/pam.d/systemd-user I see:
account include system-auth
and
session include system-auth
So, I suppose, you've put something in your /etc/pam.d/system-auth file that's making either the account stack or session stack fail.
OK, not in fact the PAM configuration but the IPA server-side configuration. Adding systemd-user as an allowed service appears to have allowed me to log in first time on the test VM. That was totally non-obvious. Particularly since this denial also happens across all our Fedora 24 machines on which users have always been able to log in first time (and have never reported any problems due to the lack of systemd-user). So I guess this bug is invalid, then. :-/ well it should probably be in the default list, moving to freeipa Unfortunately I don't have the time at the moment to truly triage the bug, but I'd like to at least point out that there is already https://bugzilla.redhat.com/show_bug.cgi?id=1474899 filed against sssd and it sounds quite like the same or very similar issue. It's the same, yes (the mention of org.freedesktop.systemd1 in the initial bug report is a red herring). *** This bug has been marked as a duplicate of bug 1474899 *** |