Bug 1862302 - Login succeeds in GDM and at console, but the user is immediately logged out after recent update
Summary: Login succeeds in GDM and at console, but the user is immediately logged out ...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: 32
Hardware: x86_64
OS: Linux
unspecified
urgent
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-07-31 00:41 UTC by psg_nm
Modified: 2020-08-06 16:05 UTC (History)
7 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2020-08-06 15:56:51 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)

Description psg_nm 2020-07-31 00:41:32 UTC 
Description of problem:

After performing an update on Fedora 32 today, no users can remain logged in.  They can try to log in at the GDM screen or at a virtual terminal (Ctrl-F2, e.g.), but as soon as the login is successful, the user is logged back out immediately.

There is no improvement after reboot either.

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

libseccomp-2.5.0-1.f32.x86_64 (correct version, but a total guess that this is the package causing the problem).

How reproducible:

I need to try it on other Fedora 32 machines.

Steps to Reproduce:
1. Performed a "sudo dnf update", which updated the following packages (taken from the dnf.log from the busted Fedora system):

  binutils-2.34-4.fc32.x86_64                                                   
  binutils-gold-2.34-4.fc32.x86_64                                              
  freerdp-2:2.2.0-1.fc32.x86_64                                                 
  freerdp-libs-2:2.2.0-1.fc32.x86_64                                            
  golang-1.14.6-1.fc32.x86_64                                                   
  golang-bin-1.14.6-1.fc32.x86_64                                               
  golang-src-1.14.6-1.fc32.noarch                                               
  google-noto-emoji-color-fonts-20200723-1.fc32.noarch                          
  libseccomp-2.5.0-1.fc32.x86_64                                                
  libwinpr-2:2.2.0-1.fc32.x86_64                                                
  tcpdump-14:4.9.3-3.fc32.x86_64   

2. Logged out (and/or reboot).
3. Can't log back in 

Actual results:

Immediately logged out after a successfully login.  Here is an example session for the "root" user (taken from the journal on the machine using a Fedora 32 KDE Live USB image and "journalctl --file":

Jul 30 15:54:31 mymachine audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=NetworkManager-dispatcher comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Jul 30 15:54:39 mymachine audit[2285]: USER_AUTH pid=2285 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 msg='op=PAM:authentication grantors=pam_unix acct="root" exe="/usr/bin/login" hostname=mymachine addr=? terminal=tty2 res=success'
Jul 30 15:54:39 mymachine audit[2285]: USER_ACCT pid=2285 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 msg='op=PAM:accounting grantors=pam_unix,pam_localuser acct="root" exe="/usr/bin/login" hostname=mymachine addr=? terminal=tty2 res=success'
Jul 30 15:54:39 mymachine audit[2285]: CRED_ACQ pid=2285 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 msg='op=PAM:setcred grantors=pam_unix acct="root" exe="/usr/bin/login" hostname=mymachine addr=? terminal=tty2 res=success'
Jul 30 15:54:39 mymachine audit[2285]: USER_ROLE_CHANGE pid=2285 uid=0 auid=0 ses=4 subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 msg='pam: default-context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 selected-context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 exe="/usr/bin/login" hostname=mymachine addr=? terminal=tty2 res=success'
Jul 30 15:54:39 mymachine systemd-logind[1264]: New session 4 of user root.
Jul 30 15:54:39 mymachine systemd[1]: Started Session 4 of user root.
Jul 30 15:54:39 mymachine login[2285]: pam_unix(login:session): session opened for user root by LOGIN(uid=0)
Jul 30 15:54:39 mymachine audit[2285]: USER_START pid=2285 uid=0 auid=0 ses=4 subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 msg='op=PAM:session_open grantors=pam_selinux,pam_loginuid,pam_console,pam_selinux,pam_namespace,pam_keyinit,pam_keyinit,pam_limits,pam_systemd,pam_unix,pam_umask,pam_lastlog acct="root" exe="/usr/bin/login" hostname=mymachine addr=? terminal=tty2 res=success'
Jul 30 15:54:39 mymachine audit[2285]: CRED_REFR pid=2285 uid=0 auid=0 ses=4 subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 msg='op=PAM:setcred grantors=pam_unix acct="root" exe="/usr/bin/login" hostname=mymachine addr=? terminal=tty2 res=success'
Jul 30 15:54:39 mymachine audit[2285]: USER_LOGIN pid=2285 uid=0 auid=0 ses=4 subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 msg='op=login id=0 exe="/usr/bin/login" hostname=mymachine addr=? terminal=tty2 res=success'
Jul 30 15:54:39 mymachine login[2285]: ROOT LOGIN ON tty2
Jul 30 15:54:39 mymachine audit[2285]: CRED_DISP pid=2285 uid=0 auid=0 ses=4 subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 msg='op=PAM:setcred grantors=pam_unix acct="root" exe="/usr/bin/login" hostname=mymachine addr=? terminal=tty2 res=success'
Jul 30 15:54:39 mymachine login[2285]: pam_unix(login:session): session closed for user root
Jul 30 15:54:39 mymachine audit[2285]: USER_END pid=2285 uid=0 auid=0 ses=4 subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 msg='op=PAM:session_close grantors=pam_selinux,pam_loginuid,pam_console,pam_selinux,pam_namespace,pam_keyinit,pam_keyinit,pam_limits,pam_systemd,pam_unix,pam_umask,pam_lastlog acct="root" exe="/usr/bin/login" hostname=mymachine addr=? terminal=tty2 res=success'
Jul 30 15:54:39 mymachine systemd[1]: getty: Succeeded.
Jul 30 15:54:39 mymachine audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=getty@tty2 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Jul 30 15:54:39 mymachine systemd[1]: session-4.scope: Succeeded.
Jul 30 15:54:39 mymachine systemd-logind[1264]: Session 4 logged out. Waiting for processes to exit.
Jul 30 15:54:39 mymachine systemd[1]: getty: Scheduled restart job, restart counter is at 2.
Jul 30 15:54:39 mymachine systemd[1]: Stopped Getty on tty2.
Jul 30 15:54:39 mymachine audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=getty@tty2 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Jul 30 15:54:39 mymachine audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=getty@tty2 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Jul 30 15:54:39 mymachine systemd[1]: Started Getty on tty2.
Jul 30 15:54:39 mymachine audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=getty@tty2 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Jul 30 15:54:39 mymachine systemd-logind[1264]: Removed session 4.


Expected results:

Login session persists until the user terminates it.

Additional info:

The laptop has run multiple versions of Fedora. It was originally installed with Fedora 25 and has been updated through Fedora 32.

The drive on the system is encrypted using LUKS.

The system seems to boot, but no one, including "root" can login with a persisting session.
Comment 1 Neal Gompa 2020-07-31 04:38:43 UTC 
This is something related to session management and login, which is handled by systemd. While I'm not ruling out libseccomp as a culprit, I don't know what in libseccomp would cause this directly, so asking systemd folks to look at this and see what's happening here.
Comment 2 Zbigniew Jędrzejewski-Szmek 2020-07-31 18:48:08 UTC 
Does it help if you update to  systemd-245.7-1.fc32 ?
Comment 3 psg_nm 2020-07-31 20:32:45 UTC 
Since I can't log in, booted from a Fedora 32 KDE Live USB device and tried the following:

dnf --installroot /run/media/liveuser/fedora-root update

That pulled in the systemd version that you mentioned along with a lot of other things.  There were a number of complaints during the update (as you might image) since it wasn't on the actual Fedora installation.

Unfortunately, it didn't make a difference (I tried booting into Fedora 32 and the login sessions immediately terminate via GDM or the virtual console).

Here is the list of updated files from the "dnf update" mentioned above:

Upgraded:
  cpp-10.2.1-1.fc32.x86_64
  firefox-79.0-3.fc32.x86_64
  freecad-1:0.18.4-10.fc32.x86_64
  freecad-data-1:0.18.4-10.fc32.noarch
  gcc-10.2.1-1.fc32.x86_64
  gcc-c++-10.2.1-1.fc32.x86_64
  gcc-gdb-plugin-10.2.1-1.fc32.x86_64
  geoclue2-2.5.6-2.fc32.x86_64
  geoclue2-libs-2.5.6-2.fc32.x86_64
  libgcc-10.2.1-1.fc32.i686
  libgcc-10.2.1-1.fc32.x86_64
  libgfortran-10.2.1-1.fc32.x86_64
  libgomp-10.2.1-1.fc32.i686
  libgomp-10.2.1-1.fc32.x86_64
  libinput-1.15.902-1.fc32.x86_64
  libipa_hbac-2.3.1-2.fc32.x86_64
  libquadmath-10.2.1-1.fc32.x86_64
  libselinux-3.0-5.fc32.i686
  libselinux-3.0-5.fc32.x86_64
  libselinux-devel-3.0-5.fc32.x86_64
  libselinux-utils-3.0-5.fc32.x86_64
  libsss_autofs-2.3.1-2.fc32.x86_64
  libsss_certmap-2.3.1-2.fc32.x86_64
  libsss_idmap-2.3.1-2.fc32.x86_64
  libsss_nss_idmap-2.3.1-2.fc32.x86_64
  libsss_sudo-2.3.1-2.fc32.x86_64
  libstdc++-10.2.1-1.fc32.i686
  libstdc++-10.2.1-1.fc32.x86_64
  libstdc++-devel-10.2.1-1.fc32.x86_64
  ostree-2020.4-2.fc32.x86_64
  ostree-libs-2020.4-2.fc32.x86_64
  python-unversioned-command-3.8.5-1.fc32.noarch
  python3-3.8.5-1.fc32.x86_64
  python3-libs-3.8.5-1.fc32.x86_64
  python3-libselinux-3.0-5.fc32.x86_64
  python3-pyside2-1:5.15.0-1.fc32.x86_64
  python3-shiboken2-1:5.15.0-1.fc32.x86_64
  python3-tkinter-3.8.5-1.fc32.x86_64
  sssd-2.3.1-2.fc32.x86_64
  sssd-ad-2.3.1-2.fc32.x86_64
  sssd-client-2.3.1-2.fc32.x86_64
  sssd-common-2.3.1-2.fc32.x86_64
  sssd-common-pac-2.3.1-2.fc32.x86_64
  sssd-ipa-2.3.1-2.fc32.x86_64
  sssd-kcm-2.3.1-2.fc32.x86_64
  sssd-krb5-2.3.1-2.fc32.x86_64
  sssd-krb5-common-2.3.1-2.fc32.x86_64
  sssd-ldap-2.3.1-2.fc32.x86_64
  sssd-nfs-idmap-2.3.1-2.fc32.x86_64
  sssd-proxy-2.3.1-2.fc32.x86_64
  systemd-245.7-1.fc32.x86_64
  systemd-container-245.7-1.fc32.x86_64
  systemd-libs-245.7-1.fc32.i686
  systemd-libs-245.7-1.fc32.x86_64
  systemd-pam-245.7-1.fc32.x86_64
  systemd-rpm-macros-245.7-1.fc32.noarch                      
  systemd-udev-245.7-1.fc32.x86_64
  vim-common-2:8.2.1307-1.fc32.x86_64
  vim-enhanced-2:8.2.1307-1.fc32.x86_64
  vim-filesystem-2:8.2.1307-1.fc32.noarch
  vim-minimal-2:8.2.1307-1.fc32.x86_64

Installed:
  qt5-qtserialport-5.14.2-1.fc32.x86_64
Comment 4 psg_nm 2020-08-06 15:56:51 UTC 
I was able to work on this a little more after updating my data backups :). I found the source of the problem, I believe.  I installed a package from my organization that installed organizational certificates on the machine about a day or so before the updates that I thought caused the problem.  I suppose that I didn't logout and login after installing the local package to notice that it was the cause of the problems.  After removing the organizational package using a live Fedora USB stick and then rebooting, I was able to login as usual.  The package itself was designed for RHEL7, but I was hoping it would work for Fedora--clearly an unfounded hope. I believe the whole problem is due to the fact that the package installs a script in /etc/profile.d and that script must be failing to run.  There was some special casing for Fedora in that profile.d script, but it looks like it is missing at least one file, which is probably why it was failing.

Sorry for the false alarm.
Comment 5 Zbigniew Jędrzejewski-Szmek 2020-08-06 16:05:14 UTC 
Cool, thanks for the explanation.
Note You need to log in before you can comment on or make changes to this bug.