Arch Linux

Is this a PAM failure? What does GDM use the gdm user for?

Yes, this seems to be a PAM failure and no idea what it uses the user for:-)

But the journald output pretty clearly states that it will not start due to the gdm user being expired:

> Sep 08 23:58:58 foobar gdm-launch-environment][755]: pam_unix(gdm-launch-environment:account): account gdm has expired (account expired)

"chage -E -1 gdm" fixes the issue for me by the way, but that is probably not a good solution.

systemd-sysusers apparently also does not offer an option to actually not expire the users it creates, so that is not a solution either.

Changing PAM might help, but that is an area of obscure magic to me:-)

If you change the account line of /etc/pam.d/gdm-launch-environment line to

account required pam_permit.so

Does that work with the expired gdm user?

gdm supplies different pam files for different distributions e.g [1] [2]

https://gitlab.gnome.org/GNOME/gdm/blob/master/data/pam-arch/gdm-launch-environment.pam
https://gitlab.gnome.org/GNOME/gdm/blob/master/data/pam-redhat/gdm-launch-environment.pam

One second, I'll install a fresh system with "account required pam_permit.so".

I would expect that to work, but let me make sure.

I reinstalled with the account line in gdm-lauch-environment changed to require pam_permit.so.

That does change something: The screen blanks now, but it stays in text mode (cursor in the upper right corner) and stays there. The UI is not started and there is no password prompt on the console.

Switching to a different console with Alt-Fx gets me to a getty and I can login there.

Looks like this needs some more tweaks:-/

I think the issue is then GDM checks if the account is not expired after pam authentication succeeds [1].

The code would need to check here if the service is gdm-launch-environment and the return code is PAM_ACCT_EXPIRED then return TRUE.
Arch could add back creating the gdm user and group in the install file otherwise this should probably be reported upstream.

https://gitlab.gnome.org/GNOME/gdm/blob/master/daemon/gdm-session-worker.c#L1324

@loqs: That is certainly possible, but changing gdm-launch-environment has at the very least made the error message mentioned in https://bugs.archlinux.org/task/63706#comment181600 disappear from journald.

Unfortunately I can't find more relevant logs in the journal.

Does uncommenting #Enable=true in the Debug section of /etc/gdm/custom.conf produce more output?

I'll do a fresh install tomorrow evening and check.

Note the sysusers file comes from Arch. It would be nice to have a viable way to ensure that packaged user accounts exist without relying on one-off useradd invocations. But this may now be impossible. :(

@eschwartz: You can always file a bug with systemd. I am pretty sure they will be open to having a flag to turn off this expired-behavior for systemd-sysusers.

Yipee:-/ Enablenig debug in /etc/gdm/custom.conf blocks me from switching to a different console and thus from logging in:-/

At least I can check the journal after a reboot:
Sep 10 22:03:52 XXX systemd[1]: Starting User Manager for UID 120...
Sep 10 22:03:52 XXX systemd[772]: pam_unix(systemd-user:account): account gdm has expired (account expired)
Sep 10 22:03:52 XXX systemd[772]: PAM failed: User account has expired
Sep 10 22:03:52 XXX systemd[772]: user@120.service: Failed to set up PAM session: Operation not permitted
Sep 10 22:03:52 XXX systemd[772]: user@120.service: Failed at step PAM spawning /usr/lib/systemd/systemd: Operation not permitted
Sep 10 22:03:52 XXX systemd[1]: user@120.service: Failed with result 'protocol'.
Sep 10 22:03:52 XXX systemd[1]: Failed to start User Manager for UID 120.

I do feel *very* uncomfortable to use pam_permit.so for account in systemd-user! That feels very wrong.

I think we need to make sure the gdm user is not expired. Best bet is probably to file an upstream bug with systemd to add an option for that?

I took the liberty to register an upstream feature request: https://github.com/systemd/systemd/issues/13522

I've tried the pam_permit fix and it succeeds for me.

(edit: It actually doesn't; I just got lucky that the user@120.service was kept running between my tests).

The system boots again when I replace the existing account lines in both gdm-launch-environment and systemd-user to be this:

account required pam_permit.so

I do not like this solution at all though: pam_permit.so will return "yeap, go ahead" for every request. No idea which whole the change to systemd-user in particular will cause!

Systemd-sysusers was changed to create expired accounts to improve overall system security. Pam_permit.so does pretty much the opposite.

Adding this line as the first account line to systemd-user should work:

account sufficient pam_succeed_if.so quiet user = gdm

Still a hack, though.

Please try gdm 3.32.0+2+g820f90f5-2. This should work on a fresh install, now.

It won't fix an existing setup, though. That still needs a `usermod --expiredate= gdm`.

lightdm also triggers a pam failure for systemd-user when account is expired but the service still started on this system

systemd[559]: pam_unix(systemd-user:account): account lightdm has expired (account expired)
systemd[559]: PAM failed: User account has expired
systemd[559]: user@991.service: Failed to set up PAM session: Operation not permitted
systemd[559]: user@991.service: Failed at step PAM spawning /usr/lib/systemd/systemd: Operation not permitted
systemd[1]: user@991.service: Failed with result 'protocol'.
systemd[1]: Failed to start User Manager for UID 991.
systemd[1]: Started Session c1 of user lightdm.

That is because lightdm specifies "optional" for pam_systemd, while gdm has "required".

Installed a brand new OS last night on new hardware and came across this bug.

On reboot after enabling the gdm service the boot process hangs after starting gdm and nothing happens, switching to another tty works so I know the system has come up ok.

Would an acceptable option be to set the GDM user account to never expire using `chage` (this works but not sure on security implications)?

I feel more uncomfortable changing systemd-user pam settings ..

I received updates today and there was gdm update too. It's "gdm-3.32.0+2+g820f90f5-2" version. Now the issue solved. I tested by reinstalling a fresh archlinux on virtualbox.

I did a fresh install with the updated package, but did not get round to test it properly yet.

I'll try to squeeze in a testing round tonight.

This is fixed for me now. Thanks!