| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
Currently, the GDM meson build has a hard dependency on systemd.
However, GDM can function just fine if one is using elogind. This allows
a user to build GDM against libelogind and also disable the systemd
system and user units.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
According to [PAM-PKCS11 User Manual][1], user can provide a empty
username and it will set username by mapped smartcard. However, this
currently does not work for gdm-smartcard, because pam_shells will fail
first on empty username.
Because [pam_shells do not check empty username before checking whether
username exists][2], we can do nothing to workaround it for empty
username, so just move it under pam_pkcs11 so it will check the
auto-detected username.
[1]: http://opensc.github.io/pam_pkcs11/doc/pam_pkcs11.html#autologin
[2]: https://github.com/linux-pam/linux-pam/commit/b52bd25910c9a8a32a49be7627a709a081a3768c
|
| |
|
|
|
| |
The insecure `user_readenv` setting has been deprecated with pam 1.5.0
and will be removed in a future release.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As mentioned in an [fprintd issue comment][1], we need to make sure that
the stack's error status is taken from the main auth module, i.e.
pam_fprintd, otherwise GDM will not behave correctly.
Still use pam_faillock preauth so that we test whether the account is
locked, but don't use authfail/authsucc to log a failure/success so this
stack doesn't participate in triggering the lock.
Ideally we would check which return values we actually want to treat as
a reason to lock the account (e.g. fingerprint mismatch) and which are
neutral (e.g. no fingerprints enrolled), but that's much more effort.
Should fix [FS#71750][2].
[1]: https://gitlab.freedesktop.org/libfprint/fprintd/-/issues/112#note_1016191
[2]: https://bugs.archlinux.org/task/71750
|
| |
|
|
|
|
|
| |
Update the PAM files for Arch Linux. This has been applied downstream
since Aug 2020.
https://bugs.archlinux.org/task/67485
|
| |
|
|
| |
Copied from pam-exherbo.
|
| |
|
|
|
|
|
|
| |
systemd-sysusers now creates expired accounts, which broke the greeter
on new installations.
Doesn't actually fully fix the problem as the user@.service still fails
to launch.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
If the user has an encrypted disk then systemd will cache the password
they type into the keyring. It makes sense to try to use this password
for automatic login purposes first, since on single user machines,
the sole user password is likely to match the disk password.
Of course if it doesn't work we'll fall back to the old way of doing
automatic login without a password (and then the user will have to
manualy enter if they need to for gnome-keyring or whatever)
https://bugzilla.gnome.org/show_bug.cgi?id=769950
|
| |
|
