Dear Maintainer,

When a user tries to log in at a romaing workstation for the very first time
the login prompt disappears, stays on the empty default-background for a few
seconds and the returns to lightdm with a brief black-screen.

On the second try everything works as expected.


I suspect that pam_mklocaluser does not properly initialize the environment
because the logs show some errors from pulseaudio as well as lightdm
trying to
write to the wrong home directory:

Jan 24 14:08:38 am-5254007fbccd.intern pulseaudio[5100]: Failed to create
secure directory (/skole/tjener/home0/teste
s/.config/pulse): Datei oder Verzeichnis nicht gefunden

Jan 24 14:08:47 am-5254007fbccd.intern lightdm[5053]: Error writing X
authority: Failed to open X authority
/skole/tjener/home0/testes/.Xauthority:
No such file or directory


This occurs on a debian-edu deployment which has been in use for about a
year
and I could also reproduce this behavior locally on a fresh install with one
mainserver VM an one romaing-workstation VM.

Regards
Nico Winkelsträter

[Nico Winkelsträter]

This is by design.  There was (and probably still is) no way to change
$HOME from the PAM subsystem when the login already was in progress.  To
work around this limitiation the user is logged logged out on the first
try, after the home directory is created and /etc/passwd is updated with
the new home location, to ensure the new home directory is used during
future logins.  The home directory is changed from
/skole/tjener/home0/testes/ to /home/testes/ in your case.

Hi Petter,

the interesting bit of information is: when using GDM3, the first
login succeeds and the session is in an intact state.

So, the follow-up question is: Why can this work in GDM3 while it
fails in LightDM?

Mike

Hi again,

please also note, that we recently changed stuff in libpam-python.so
and also fixed a pam_session related bug in unit tests. I still need
to test the Python3 port of libpam-python.so containing this fix (it's
in Debian testing already) to see if above issue reported by Nico is
possibly resolved.

Mike

This is actually a bug in LightDM which makes assumptions about the home
directory not changing and hardcoding paths to the Xauthority file.

There is also a small fix for libpam-mklocaluser necessary so it runs
before the pam_systemd module so that systemd/DBus started processes
have the correct home directory.

If you want to test, you need to rebuild lightdm with the patch from
https://github.com/canonical/lightdm/pull/323 and change the
libpam-mklocaluser pam-config priority.

The latter is necessary for other display managers as well.

Hi Guido,

Thanks for digging this out!!!

I'll need to see how we can escalate this to the lightdm maintainer in
Debian. Unfortunately, neither lightdm upstream nor downstream is
really active with development.

Interestingly, with GDMv3 (bullseye version), the login would just
work on first attempt.

Mike

I'll prepare a patch for the package based on the above PR.

GDM might handle the login better but everything started by systemd and
DBus will likely have the wrong home directory because of the order of
session type PAM modules.

Just merged that:
https://salsa.debian.org/debian-edu/upstream/libpam-mklocaluser/-/merge_requests/2

Mike