Bug 1335511 - gdm with X: fully reproducible failure: VT_ACTIVATE: Operation not permitted
Summary: gdm with X: fully reproducible failure: VT_ACTIVATE: Operation not permitted
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: gdm
Version: 23
Hardware: Unspecified
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Ray Strode [halfline]
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-05-12 11:44 UTC by Alan Jenkins
Modified: 2016-12-20 20:27 UTC (History)
4 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2016-12-20 20:27:40 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Alan Jenkins 2016-05-12 11:44:58 UTC
Description of problem:

A simple test case causes X to fail to start, when it should work.  The error is VT_ACTIVATE: Operation not permitted.

The test case is to runs gdm under X (not Wayland), log in to gdm (and log out), then log in to a text console and restart gdm.

Those first two steps are necessary to reproduce the failure.  If either one is omitted, then it seems to work correctly.


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

xorg-x11-server-Xorg-1.18.3-2.fc23.x86_64


How reproducible: I think it's a universal bug (not hardware-dependent).

I reproduced it on my Thinkpad X201.  Originally I noticed it on a Braswell NUC with flaky graphics.


Steps to Reproduce:
1. Install Fedora 23 Workstation
2. Edit /etc/gdm/custom.conf to disable Wayland, and reboot.
3. Use GDM to log in.  Then log out.
4. ctrl+alt+f3; log in to text console
5. systemctl restart gdm

Actual results:

The display flickers, as X continuously fails and is restarted.  Errors are logged like this:




May 12 11:33:19 localhost.localdomain /usr/libexec/gdm-x-session[5831]: (WW) xf86OpenConsole: VT_ACTIVATE failed: Operation not permitted
May 12 11:33:19 localhost.localdomain /usr/libexec/gdm-x-session[5831]: (EE)
May 12 11:33:19 localhost.localdomain /usr/libexec/gdm-x-session[5831]: Fatal server error:
May 12 11:33:19 localhost.localdomain /usr/libexec/gdm-x-session[5831]: (EE) xf86OpenConsole: Switching VT failed
May 12 11:33:19 localhost.localdomain /usr/libexec/gdm-x-session[5831]: (EE)
May 12 11:33:19 localhost.localdomain /usr/libexec/gdm-x-session[5831]: (EE)
May 12 11:33:19 localhost.localdomain /usr/libexec/gdm-x-session[5831]: Please consult the Fedora Project support
May 12 11:33:19 localhost.localdomain /usr/libexec/gdm-x-session[5831]: at http://wiki.x.org
May 12 11:33:19 localhost.localdomain /usr/libexec/gdm-x-session[5831]: for help.
May 12 11:33:19 localhost.localdomain /usr/libexec/gdm-x-session[5831]: (EE) Please also check the log file at "/var/lib/gdm/.local/share/xorg/Xorg.0.log" for additional information.
May 12 11:33:19 localhost.localdomain /usr/libexec/gdm-x-session[5831]: (EE)
May 12 11:33:19 localhost.localdomain /usr/libexec/gdm-x-session[5831]: (WW) xf86CloseConsole: KDSETMODE failed: Operation not permitted
May 12 11:33:19 localhost.localdomain /usr/libexec/gdm-x-session[5831]: (WW) xf86CloseConsole: VT_SETMODE failed: Operation not permitted
May 12 11:33:19 localhost.localdomain /usr/libexec/gdm-x-session[5831]: (WW) xf86CloseConsole: VT_ACTIVATE failed: Operation not permitted
May 12 11:33:19 localhost.localdomain /usr/libexec/gdm-x-session[5831]: (EE) Server terminated with error (1). Closing log file.
May 12 11:33:19 localhost.localdomain /usr/libexec/gdm-x-session[5831]: Unable to run X server




Expected results:

It's expected that gdm should start successfully in this test.

Usually the console would switch from the text console to GDM.


Additional info:

I hypothesize it happens because

a) X is running as non-root (yay)
b) for some reason, X fails or forgets to get systemd-logind to switch the VT on its behalf.  Then it tries to switch VTs itself, without having the necessary privilege.


Unfortunately I can see no other errors interleaved or preceding the Xorg error.

The log shows that as GDM starts, it is at least granted a session by systemd-logind (see below).  




May 12 11:33:18 localhost.localdomain systemd[1]: Starting GNOME Display Manager...
May 12 11:33:18 localhost.localdomain systemd[1]: Started GNOME Display Manager.
May 12 11:33:18 localhost.localdomain audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 ms
g='unit=gdm comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
May 12 11:33:18 localhost.localdomain sudo[5707]: pam_unix(sudo:session): session closed for user root
May 12 11:33:18 localhost.localdomain audit[5707]: USER_END pid=5707 uid=0 auid=1001 ses=3 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0
:c0.c1023 msg='op=PAM:session_close grantors=pam_keyinit,pam_limits,pam_keyinit,pam_limits,pam_systemd,pam_unix acct="root" exe="/usr/bin/su
do" hostname=? addr=? terminal=/dev/tty2 res=success'
May 12 11:33:18 localhost.localdomain audit[5707]: CRED_DISP pid=5707 uid=0 auid=1001 ses=3 subj=unconfined_u:unconfined_r:unconfined_t:s0-s
0:c0.c1023 msg='op=PAM:setcred grantors=pam_env,pam_fprintd acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/tty2 res=success
'
May 12 11:33:18 localhost.localdomain audit[5738]: USER_AUTH pid=5738 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s
0:c0.c1023 msg='op=PAM:authentication grantors=pam_permit acct="gdm" exe="/usr/libexec/gdm-session-worker" hostname=? addr=? terminal=? res=
success'
May 12 11:33:18 localhost.localdomain audit[5738]: USER_ACCT pid=5738 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s
0:c0.c1023 msg='op=PAM:accounting grantors=pam_unix,pam_localuser acct="gdm" exe="/usr/libexec/gdm-session-worker" hostname=? addr=? termina
l=? res=success'
May 12 11:33:18 localhost.localdomain audit[5738]: CRED_ACQ pid=5738 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0
:c0.c1023 msg='op=PAM:setcred grantors=pam_permit acct="gdm" exe="/usr/libexec/gdm-session-worker" hostname=? addr=? terminal=? res=success'
May 12 11:33:18 localhost.localdomain polkitd[946]: Unregistered Authentication Agent for unix-process:5708:1026789 (system bus name :1.131,
 object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_GB.UTF-8) (disconnected from bus)
May 12 11:33:18 localhost.localdomain audit[1]: USER_AVC pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='Un
known permission start for class system exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?'
May 12 11:33:18 localhost.localdomain systemd-logind[908]: New session c2 of user gdm.
May 12 11:33:18 localhost.localdomain systemd[1]: Started Session c2 of user gdm.
May 12 11:33:18 localhost.localdomain systemd[1]: Starting Session c2 of user gdm.
May 12 11:33:18 localhost.localdomain gdm-launch-environment][5738]: pam_unix(gdm-launch-environment:session): session opened for user gdm b
y (uid=0)
May 12 11:33:18 localhost.localdomain audit[5738]: USER_START pid=5738 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-
s0:c0.c1023 msg='op=PAM:session_open grantors=pam_keyinit,pam_keyinit,pam_limits,pam_systemd,pam_unix acct="gdm" exe="/usr/libexec/gdm-sessi
on-worker" hostname=? addr=? terminal=/dev/tty1 res=success'
May 12 11:33:19 localhost.localdomain /usr/libexec/gdm-x-session[5831]: (--) Log file renamed from "/var/lib/gdm/.local/share/xorg/Xorg.pid-
5837.log" to "/var/lib/gdm/.local/share/xorg/Xorg.0.log"
May 12 11:33:19 localhost.localdomain /usr/libexec/gdm-x-session[5831]: X.Org X Server 1.18.3
May 12 11:33:19 localhost.localdomain /usr/libexec/gdm-x-session[5831]: Release Date: 2016-04-04

Comment 1 Hans de Goede 2016-05-12 12:04:40 UTC
Seems like a gdm bug to me, changing component.

Comment 2 Ray Strode [halfline] 2016-05-12 17:36:31 UTC
do you mind filing this on bugzilla.gnome.org ?

Comment 3 Alan Jenkins 2016-05-12 19:05:20 UTC
That was a bit unfair to ask :-P.  I said I thought it was a bug in X and Hans didn't mention why not.  I see Hans should know about this stuff.

I was worrying at this earlier & ran some tests.  Can you confirm my surmise please?  Then I will have an informed description I can file with GNOME.


1. gdm is running /usr/libexec/Xorg as non-root.
2. Xorg as non-root can _not_ switch VTs.  And it's not that it ever uses a logind API to request VT switches.  (ala `loginctl activate`)
3. Therefore gdm has taken responsibility for switching to the desired VT.  It looks like gdm is failing to do so in this case.


Test:

$ tty
/dev/tty3

$ /usr/libexec/Xorg :1 vt3
[success]

$ /usr/libexec/Xorg :1
[failure, misleading error message about tty0 not existing]

$ /usr/libexec/Xorg.wrap :1
[success, yay :)  Xorg switches to a free VT as is traditional.  By brute-force: Xorg is shown running as root.  Boo :(]

Comment 4 Ray Strode [halfline] 2016-05-12 19:18:31 UTC
i'm not trying to be unfair, just trying to keep all gdm bugs in one place! if it's an inconvenience for you to file it upstream, I can do it.

GDM should be jumping to and forcing VT1 when it first starts.  The code is there, there just must be a bug...

Comment 5 Ernst Persson 2016-06-29 00:14:28 UTC
I have this bug on Ubuntu Gnome FYI.

Comment 6 Fedora End Of Life 2016-11-25 09:01:00 UTC
This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '23'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 23 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 7 Fedora End Of Life 2016-12-20 20:27:40 UTC
Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.


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