Bug 1473806 - User cannot log in: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: No display available
User cannot log in: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: No d...
Status: CLOSED DUPLICATE of bug 1474899
Product: Fedora
Classification: Fedora
Component: freeipa (Show other bugs)
26
Unspecified Unspecified
unspecified Severity high
: ---
: ---
Assigned To: IPA Maintainers
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-07-21 13:39 EDT by Ian Collier
Modified: 2017-08-14 04:56 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-08-14 04:56:52 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Debug log of a login failure (67.02 KB, text/plain)
2017-08-02 14:11 EDT, Ian Collier
no flags Details

  None (edit)
Description Ian Collier 2017-07-21 13:39:00 EDT
With apologies in advance, this is complicated, may involve more than one
bug and/or component, and can't easily be tested because this is on a user's
production machine.

Summary is: user types username and password into the gdm login box, and
his session fails to start and returns him to gdm. If we then switch to VT2
and then back to VT1 then the next login will probably succeed.  There are
two different failure messages in the logs:

1. systemd: user@12060.service: Failed at step PAM spawning /usr/lib/systemd/systemd: Operation not permitted

2. /usr/libexec/gdm-x-session: (EE) xf86OpenConsole: Cannot open virtual console 2 (Permission denied)

It's this second message that seems to be fixed by the VT switch.  But
the VT switch doesn't work unless the user has already tried to log in.
If we try the VT switch before logging in, then the permission error 
happens on virtual console 3 instead of 2, and that's the console we
now have to switch to in order to fix the error.

This machine was running Fedora 24 and was upgraded to Fedora 26 yesterday
morning.  This wasn't without incident, but we are now at a point where
"dnf repoquery --unsatisfied" and "dnf repoquery --duplicated" both say
nothing, and "dnf distro-sync" says nothing except about the kernel.
I have installed a build of kernel 4.12.0 from Rawhide because the user
was experiencing bug 1441906 on a daily basis (but I tried temporarily
downgrading the kernel and it didn't fix the problem).

In addition, the boot options systemd.legacy_systemd_cgroup_controller=1
and systemd.unified_cgroup_hierarchy=0 are currently being used, because
message (1) above led me through a long trail to bug 1435142 where this
is suggested, although that might in fact be irrelevant to the current
problem.

The machine has Intel HD Graphics 530 and initially Xorg was using the
"modesetting driver" and gdm was on the default of Wayland, though in
the current configuration Xorg is using the "intel" driver and gdm is
using Xorg.  All kinds of login desktop were tried, mostly Xorg-based
but the user was also unable to log in to a Wayland GNOME session.
The user who can't log in is a networked user (IPA server + automount
home directory) but we have also reproduced the problem with a local user.

Currently we have: kernel 4.12.0; legacy cgroups specified on the kernel
command line; gdm on Xorg, disable-user-list=true, and the user is logging
in with GNOME on Xorg.  And SELinux is completely disabled.  In this 
configuration, the workaround described at the top of this bug report
is mostly working.
Comment 1 Ian Collier 2017-08-02 07:26:00 EDT
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.
Comment 2 Ian Collier 2017-08-02 11:57:25 EDT
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.)
Comment 3 Ian Collier 2017-08-02 14:11 EDT
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).
Comment 4 Ray Strode [halfline] 2017-08-02 16:51:24 EDT
> 1. systemd: user@12060.service: 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.
Comment 5 Ian Collier 2017-08-03 06:18:58 EDT
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. :-/
Comment 6 Ray Strode [halfline] 2017-08-03 14:29:57 EDT
well it should probably be in the default list, moving to freeipa
Comment 7 Jakub Hrozek 2017-08-03 15:05:32 EDT
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.
Comment 8 Ian Collier 2017-08-03 15:51:52 EDT
It's the same, yes (the mention of org.freedesktop.systemd1 in the initial bug report is a
red herring).
Comment 9 Petr Vobornik 2017-08-14 04:56:52 EDT

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

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