#1052389 First login with libpam-mklocaluser always fails

Package:
lightdm
Source:
lightdm
Description:
simple display manager
Submitter:
Guido Berhoerster
Date:
2024-04-25 18:00:38 UTC
Severity:
normal
Tags:
#1052389#5
Date:
2023-09-21 09:35:47 UTC
From:
To:
This is a problem that manifests itself in DebianEdu where roaming
workstations obtain user information from LDAP from the school network
on the first login and then proceeds to create a local user account and
home directory based on that data.  That is accomplished by a python
script provided by libpam-mklocaluser which is run after successful
authentication when opening the pam session via the pam_python PAM
module.

When logging in with LightDM the first login always fails due to a
discrepancy between the the home directory obtained from LDAP via
getpwent() and the newly created home directory. Specifically, the
LightDM daemon communicates the absolute path of the Xauthority file to
the session child process and sets the HOME environment variable to the
value obtained via getpwent() and uses that value to change the working
directory, all resulting in fatal errors.

#1052389#10
Date:
2023-09-21 10:02:02 UTC
From:
To:
[Guido Berhoerster]

There used to be code in libpam-mklocaluser to throw the user out after
the home directory is created, to ensure that the user is not logged in
with the wrong $HOME set.  Is this not happening with LightDM?  Because
$HOME change after some processes read it, it is not possible to both
create the local home directory and continue with the login.

Or are you talking about being thrown out by libpam-mklocaluser when
logging in for the first time?  This is by design and intented due to
the protocol provided by PAM.

#1052389#15
Date:
2023-09-21 11:53:59 UTC
From:
To:
Am 21.09.23 um 12:02 schrieb Petter Reinholdtsen:


No, I'm not talking about either. libpam-mklocaluser does not
intentionally fail the first login, rather in case of LightDM there is a
cascade of errors due to its assumption that the home directory stays
the same when the PAM session is opened as well as the daemon hardcoding
the Xauthority file path to <passwd->pw_dir>/.Xauthority and passing that
to the session child.  Both can be fixed and I have a patch for LightDM.

That leaves the systemd user instance and services started by it (e.g.
DBus, pipewire, gnome-keyring on MATE). That can be fixed by giving the
libpam-mklocaluser PAM config a higher priority than everything else so
that getpwent() and $HOME from PAM point to the correct directory.

At least with LightDM and MATE I have a working first login where all
processes have the correct HOME.

#1052389#24
Date:
2023-09-21 18:18:02 UTC
From:
To:
That kickout code got dropped from libpam-mklocaluser because with
GDM3 there was no evident problem. So, we went towards getting that
kick-out solved rather than adding an artificial logout:
https://salsa.debian.org/debian-edu/upstream/libpam-mklocaluser/-/commit/407497044bd135bc013d32a83b091f35a9ae3abf

However, as Guido discovered today, the session might have still been
ok in GNOMEv3 (tested in bullseye), but the associated systemd --user
services probably were not.

It is not intended by design anymore...

Mike