# NSS + GDM Issue

##### 1. GDM Requests a Dynamic User

When GDM starts up it attempts to launch the graphical login screen. For security isolation GDM requests a session for a systemd dynamic user named `gdm-greeter` from `systemd-logind`.
   * Systemd dynamically allocated a UID (60578 in this case) and registered the username gdm-greeter to it.
   * Logind triggers the creation of the user's slice and runtime directory
     ```
     systemd[1]: Created slice User Slice of UID 60578.
     systemd-logind[426]: New session '1' of user 'gdm-greeter' with class 'greeter' and type 'wayland'.
     ```

##### 2. Systemd Spawns the User Manager and Invokes PAM
  
To run the background GNOME session, systemd attempts to spawn the per-user systemd instance (user@60578.service).

Before launching the service, systemd must authenticate and initialize the user's environment using the PAM  stack configured in `/etc/pam.d/systemd-user` (which inherits `/etc/pam.d/system-auth`).

##### 3. pam_sss.so Gracefully Rejects the Dynamic User

First, the account block in the PAM stack runs pam_sss.so:
   ```
   account    sufficient                  pam_sss.so
   ```
   * pam_sss queries the SSSD daemon: "Do you have a user named gdm-greeter?"
   * SSSD queries your LDAP server and finds nothing. SSSD replies: "No, this user is unknown to me."
   * This generates the log entry:
   ```
   1   (systemd)[508]: pam_sss(systemd-user:account): Access denied for user gdm-greeter: 10 (User not known to the underlying authentication module)
   ```
   * Because pam_sss is configured as sufficient, its failure is non-fatal. PAM ignores this rejection and falls through to the next module in the stack: pam_unix.so.

##### 4. pam_unix.so Spawns unix_chkpwd

To verify the local account, pam_unix.so spawns the setuid helper binary /usr/bin/unix_chkpwd to check the user's password and shadow database info:
```
1 account    required                    pam_unix.so
```

##### 5. The Silent NSS Database Lookup Failure
Inside the C code of /usr/bin/unix_chkpwd, the program makes a standard glibc library call to look up the shadow password entry for the username:

   ```
   1 getspnam("gdm-greeter"); 
   ```
  To resolve this call, glibc reads your `/etc/nsswitch.conf` file to see which databases are registered under the shadow: line. It saw:

   ```
   1 shadow: compat sss
   ```

Glibc began querying the modules in order:

   1. compat (local files): It searched /etc/shadow for an entry starting with gdm-greeter:. Since gdm-greeter is a dynamic user, no such line exists in /etc/shadow. This returns:
  ```
  NSS_STATUS_NOTFOUND.
  ```
   2. sss (SSSD): It asked SSSD if it has a cached shadow record for gdm-greeter. SSSD does not. This returns NSS_STATUS_NOTFOUND.

  Because systemd was missing from that line, glibc reached the end of the databases and stopped. It never queried nss-systemd (which is the only place where GDM's dynamic users are registered).

  As a result, getspnam("gdm-greeter") returned NULL (No such entry).

##### 6. PAM Crashes, Locking Out the Session
   * unix_chkpwd realized it was completely blind to this user and threw an error:
   ```
   unix_chkpwd[509]: could not obtain user info (gdm-greeter)
   ```
   * Because unix_chkpwd failed, pam_unix.so returned a fatal error to PAM.
   * Because pam_unix.so is required, the entire PAM transaction aborted:
   ```
   (systemd)[508]: PAM PAM failed: Authentication service cannot retrieve authentication info
   ```
   * Systemd saw the PAM initialization failure and immediately aborted spawning the user manager:
   ```
   (systemd)[508]: user@60578.service: Failed to set up PAM session: Operation not permitted
   (systemd)[508]: user@60578.service: Failed at step PAM spawning /usr/lib/systemd/systemd: Operation not permitted
   systemd[1]: Failed to start User Manager for UID 60578.
   ```

##### 7. Crash and Lockout

Without a running systemd --user manager for UID 60578, the user-level D-Bus broker (org.freedesktop.systemd1) was never launched.

When the GDM Wayland session tried to initialize gnome-session, it attempted to talk to the systemd user manager over D-Bus. This lookup failed, causing the greeter worker to throw an unhandled assertion and crash (dumping core):
   ```
   gnome-session-i[518]: Failed to start unit gnome-session@gnome.target: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Name "org.freedesktop.systemd1" does not exist
   systemd-coredump[527]: Process 518 (gnome-session-i) of user 60578 dumped core.
   ```

GDM attempted to restart this sequence six times, failing every time, until it reached its failure threshold:
   ```
   gdm[455]: Gdm: GdmLocalDisplayFactory: maximum number of display failures reached. Giving up.
   ```

At this point, GDM completely gave up on opening any graphical interfaces on your screen, leaving the system stuck in the console/tty mode.

By adding systemd back to the shadow: line in /etc/nsswitch.conf, the glibc call getspnam("gdm-greeter") was able to query nss-systemd, retrieve the dynamic user's shadow record, pass the PAM stack, start the user manager, and successfully launch the login screen.