Silverblue -> Kinoite : Issue with SDDM and PAM

I recently installed Cockpit and noticed that I have this error:

Screenshot

Text Version
journalctl --no-tail --since=-24hours --reverse -- _SYSTEMD_UNIT=user@975.service + COREDUMP_UNIT=user@975.service + UNIT=user@975.service
Apr 12 13:27:32 fedora-pc systemd[1]: Failed to start User Manager for UID 975.
Apr 12 13:27:32 fedora-pc systemd[1]: user@975.service: Failed with result 'exit-code'.
Apr 12 13:27:32 fedora-pc systemd[1]: user@975.service: Main process exited, code=exited, status=224/PAM
Apr 12 13:27:32 fedora-pc systemd[1501]: user@975.service: Failed at step PAM spawning /usr/lib/systemd/systemd: Operation not permitted
Apr 12 13:27:32 fedora-pc systemd[1501]: user@975.service: Failed to set up PAM session: Operation not permitted
Apr 12 13:27:32 fedora-pc systemd[1501]: PAM failed: Authentication service cannot retrieve authentication info
Apr 12 13:27:32 fedora-pc systemd[1]: Starting User Manager for UID 975...
-- Boot 890acb19bf9147a8a2469fa3d0685ea3 --
Apr 12 13:02:04 fedora-pc systemd[1]: Failed to start User Manager for UID 975.
Apr 12 13:02:04 fedora-pc systemd[1]: user@975.service: Failed with result 'exit-code'.
Apr 12 13:02:04 fedora-pc systemd[1]: user@975.service: Main process exited, code=exited, status=224/PAM
Apr 12 13:02:04 fedora-pc systemd[35393]: user@975.service: Failed at step PAM spawning /usr/lib/systemd/systemd: Operation not permitted
Apr 12 13:02:04 fedora-pc systemd[35393]: user@975.service: Failed to set up PAM session: Operation not permitted
Apr 12 13:02:04 fedora-pc systemd[35393]: PAM failed: Authentication service cannot retrieve authentication info
Apr 12 13:02:04 fedora-pc systemd[1]: Starting User Manager for UID 975...
Apr 12 13:01:57 fedora-pc systemd[1]: Failed to start User Manager for UID 975.
Apr 12 13:01:57 fedora-pc systemd[1]: user@975.service: Failed with result 'exit-code'.
Apr 12 13:01:57 fedora-pc systemd[1]: user@975.service: Main process exited, code=exited, status=224/PAM
Apr 12 13:01:57 fedora-pc systemd[35391]: user@975.service: Failed at step PAM spawning /usr/lib/systemd/systemd: Operation not permitted
Apr 12 13:01:57 fedora-pc systemd[35391]: user@975.service: Failed to set up PAM session: Operation not permitted
Apr 12 13:01:57 fedora-pc systemd[35391]: PAM failed: Authentication service cannot retrieve authentication info
Apr 12 13:01:57 fedora-pc systemd[1]: Starting User Manager for UID 975...

User 975 is SDDM. The most notable consideration here is that this system was rebased from Silverblue 34 to Kinoite 35, so it started out with GDM. I think this is important to note because I have another second machine that I have a fresh install of Kinoite 35 and that machine does not have any of these errors. Furthermore, on the machine that does have these issues, the /etc/shadow file contains an entry for gdm, but no entry for sddm. Whereas on the machine that was a fresh Kinoite install, there is no gdm entry, and there is an entry for sddm.

My assumption here is that the sddm user was not created completely/correctly when the system was rebased from Silverblue to Kinoite. But I don’t know what needs to be done to fix this. Any help is appreciated. Thanks.

1 Like

I don’t have any ideas here, either. I almost went the opposite direction recently (upgrading major version from Kinoite to Silverblue) by accident but caught it before rebooting. Since then, I’ve been curious about if this is supported, especially since both Silverblue and Kinoite are presented in cockpit (with cockpit-ostree layered in).

A few more clues (maybe)? Running systemd-cgls, I get the following output. I noticed that there is a user-975.slice still running, whereas that does not occur on the “clean” Kinoite system.

systemd-cgls
systemd-cgls                 
Control group /:
-.slice
├─user.slice 
│ ├─user-1000.slice 
...
│ └─user-975.slice 
│   └─session-c1.scope 
│     ├─1490 dbus-launch --autolaunch 9c57b3bdc5ec4a30bb471488fa840d7d --binary-syntax --close-stderr
│     └─1491 /usr/bin/dbus-daemon --syslog-only --fork --print-pid 5 --print-address 7 --session

Querying that scope, I get:

session-c1.scope
systemctl status session-c1.scope            
● session-c1.scope - Session c1 of User sddm
     Loaded: loaded (/run/systemd/transient/session-c1.scope; transient)
  Transient: yes
     Active: active (abandoned) since Wed 2022-04-13 10:05:36 CDT; 21min ago
      Tasks: 2
     Memory: 115.5M
        CPU: 616ms
     CGroup: /user.slice/user-975.slice/session-c1.scope
             ├─1490 dbus-launch --autolaunch 9c57b3bdc5ec4a30bb471488fa840d7d --binary-syntax --close-stderr
             └─1491 /usr/bin/dbus-daemon --syslog-only --fork --print-pid 5 --print-address 7 --session

Apr 13 10:05:36 fedora-pc sddm-greeter[1484]: QObject: Cannot create children for a parent that is in a different thread.
                                              (Parent is QGuiApplication(0x7ffe898dfe00), parent's thread is QThread(0x5571176a5bb0), current thread is QThread(0x5571177fd550)
Apr 13 10:05:36 fedora-pc sddm-greeter[1484]: QObject: Cannot create children for a parent that is in a different thread.
                                              (Parent is QGuiApplication(0x7ffe898dfe00), parent's thread is QThread(0x5571176a5bb0), current thread is QThread(0x5571177fd550)
Apr 13 10:05:36 fedora-pc sddm-greeter[1484]: QObject: Cannot create children for a parent that is in a different thread.
                                              (Parent is QGuiApplication(0x7ffe898dfe00), parent's thread is QThread(0x5571176a5bb0), current thread is QThread(0x5571177fd550)
Apr 13 10:05:36 fedora-pc sddm-greeter[1484]: QObject::installEventFilter(): Cannot filter events for objects in a different thread.
Apr 13 10:05:37 fedora-pc sddm-greeter[1484]: Warning: Theme implementations should use Kirigami.BasicThemeDefinition for its root item
Apr 13 10:05:37 fedora-pc sddm-greeter[1484]: Cannot watch QRC-like path ":/icons/hicolor/index.theme"
Apr 13 10:09:01 fedora-pc sddm-helper[1476]: pam_unix(sddm-greeter:session): session closed for user sddm
Apr 13 10:09:01 fedora-pc sddm-helper[1476]: pam_unix(sddm-greeter:session): session closed for user sddm
Apr 13 10:09:01 fedora-pc sddm-helper[1476]: pam_systemd(sddm-greeter:session): Failed to release session: Transport endpoint is not connected
Apr 13 10:09:01 fedora-pc sddm-helper[1476]: [PAM] closeSession: Cannot make/remove an entry for the specified session

I’m really not knowledgeable with PAM and DBUS to know what’s going on. Hopefully there are some clues in here.

1 Like

After further digging, I think the clues above aren’t relevant. But I found something else. Here is where the authentication is failing:

Apr 13 10:39:54 fedora-pc systemd[1]: Starting User Manager for UID 975...
Apr 13 10:39:54 fedora-pc unix_chkpwd[1483]: could not obtain user info (sddm)
Apr 13 10:39:54 fedora-pc audit[1482]: USER_ACCT pid=1482 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='op=PAM:accounting grantors=? acct="sddm" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed'

Looking at where it says grantors=?, on the working system it is grantors=pam_unix. So what is “grantors”, and how do I associate “pam_unix” as the grantor for the ‘sddm’ user?

Solved! Turns out my first clue regarding /etc/shadow was the correct culprit all along. And for those who are interested in rebasing from Silverblue to Kinoite or vice-versa, this is an additional step in addition to the official unofficial instructions for the rebase. Note: this error didn’t actually affect the system - I’ve been using it like this for months since Kinoite 35 came out. But the error has been there, and that…bugged me.

Googling the “PAM:accounting grantors=?” error hinted that the user is missing from /etc/shadow. Looking at the /etc/passwd file on a Silverblue/Kinoite system is pretty confusing because it’s pretty bare - mine only has entries for root and myself. Whereas the /etc/shadow file has many more entries. It wasn’t clear until playing with getent passwd -s and looking into the /etc/nsswitch.conf file that it was evident that Silverblue/Kinoite uses the nss-altfiles module. It makes perfect sense now, of course, since we would want to store that info in /lib/passwd instead of /etc/passwd, since /lib is part of the ostree whereas /etc is mutable.

nsswitch.conf
# Generated by authselect on Tue Aug 31 14:25:43 2021
# Do not modify this file manually.

# If you want to make changes to nsswitch.conf please modify
# /etc/authselect/user-nsswitch.conf and run 'authselect apply-changes'.
#
# Note that your changes may not be applied as they may be
# overwritten by selected profile. Maps set in the authselect
# profile takes always precedence and overwrites the same maps
# set in the user file. Only maps that are not set by the profile
# are applied from the user file.
#
# For example, if the profile sets:
#     passwd: sss files
# and /etc/authselect/user-nsswitch.conf contains:
#     passwd: files
#     hosts: files dns
# the resulting generated nsswitch.conf will be:
#     passwd: sss files # from profile
#     hosts: files dns  # from user file

passwd:     sss files systemd altfiles
group:      sss files systemd altfiles
netgroup:   sss files
automount:  sss files
services:   sss files

But problematically there’s no corresponding module for the shadow file. So there is only /etc/shadow. It doesn’t get overwritten by an ostree rebase/upgrade. So that means that the sddm user that replaced gdm in /lib/passwd never had the same change cascaded down to /etc/shadow.

TLDR; use sudo vipw -s to edit the /etc/shadow file manually and add the sddm user. I don’t particularly like the idea of manually updating the shadow file, but I couldn’t (in my short time looking) find a tool (e.g. pwconv) that would look at the /lib/passwd file as most tools expect everything to be in /etc. If there’s a better option, please let me know.

Pretty neat to learn new stuff every day. Yay to Linux and OSS, that allows us to peek under the covers and figure out what’s going on and fix pretty much anything with some research.

2 Likes