Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#63706 - [gdm] Gdm will not start due to gdm used created by systemd-sysusers

Attached to Project: Arch Linux
Opened by Tobias Hunger (hunger) - Monday, 09 September 2019, 16:56 GMT
Last edited by Jan Alexander Steffens (heftig) - Friday, 13 September 2019, 22:07 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Jan de Groot (JGC)
Jan Alexander Steffens (heftig)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Description:
Since version 243 systemd-sysusers will produce system users with expired accounts. You can check this by running
"chage -l gdm" in a pacstrap directory.

This is an intentional change in systemd (see comments in  FS#63704 ).

Gdm will not start in such a setup: It detects that the account is expired and will not start.

Additional info:
* systemd 243.0-1

Steps to reproduce:
This task depends upon

Closed by  Jan Alexander Steffens (heftig)
Friday, 13 September 2019, 22:07 GMT
Reason for closing:  Fixed
Additional comments about closing:  gdm 3.32.0+2+g820f90f5-2
Comment by loqs (loqs) - Monday, 09 September 2019, 17:23 GMT
Is this a PAM failure? What does GDM use the gdm user for?
Comment by Tobias Hunger (hunger) - Monday, 09 September 2019, 18:36 GMT
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:-)
Comment by loqs (loqs) - Monday, 09 September 2019, 19:22 GMT
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
Comment by Tobias Hunger (hunger) - Monday, 09 September 2019, 19:40 GMT
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.
Comment by Tobias Hunger (hunger) - Monday, 09 September 2019, 20:09 GMT
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:-/
Comment by loqs (loqs) - Monday, 09 September 2019, 20:46 GMT
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
Comment by Tobias Hunger (hunger) - Monday, 09 September 2019, 20:50 GMT
@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.
Comment by loqs (loqs) - Monday, 09 September 2019, 20:56 GMT
Does uncommenting #Enable=true in the Debug section of /etc/gdm/custom.conf produce more output?
Comment by Tobias Hunger (hunger) - Monday, 09 September 2019, 21:28 GMT
I'll do a fresh install tomorrow evening and check.
Comment by Eli Schwartz (eschwartz) - Tuesday, 10 September 2019, 14:36 GMT
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. :(
Comment by Tobias Hunger (hunger) - Tuesday, 10 September 2019, 19:43 GMT
@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.
Comment by Tobias Hunger (hunger) - Tuesday, 10 September 2019, 20:17 GMT
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?
Comment by Tobias Hunger (hunger) - Tuesday, 10 September 2019, 20:27 GMT
I took the liberty to register an upstream feature request: https://github.com/systemd/systemd/issues/13522
Comment by Jan Alexander Steffens (heftig) - Tuesday, 10 September 2019, 20:44 GMT
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).
Comment by Tobias Hunger (hunger) - Tuesday, 10 September 2019, 20:49 GMT
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.
Comment by Jan Alexander Steffens (heftig) - Tuesday, 10 September 2019, 20:59 GMT
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.
Comment by Jan Alexander Steffens (heftig) - Tuesday, 10 September 2019, 21:21 GMT
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`.
Comment by loqs (loqs) - Tuesday, 10 September 2019, 21:25 GMT
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.
Comment by Jan Alexander Steffens (heftig) - Tuesday, 10 September 2019, 21:30 GMT
That is because lightdm specifies "optional" for pam_systemd, while gdm has "required".
Comment by Kevin Andrews (caffe1neadd1ct) - Wednesday, 11 September 2019, 06:58 GMT
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 ..
Comment by Rizwan Hasan (Rizwan486) - Wednesday, 11 September 2019, 20:49 GMT
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.
Comment by Tobias Hunger (hunger) - Thursday, 12 September 2019, 07:59 GMT
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.
Comment by Tobias Hunger (hunger) - Friday, 13 September 2019, 20:29 GMT
This is fixed for me now. Thanks!

Loading...