On Sun, May 26, 2024 at 07:01:30PM +0100, Luca Boccassi wrote: > Control: tags -1 help
> This is the pam config I ship: > # cat /usr/share/pam-configs/systemd-homed > Name: Enable user management by systemd-homed > Default: yes > Priority: 257 > Auth-Type: Primary > Auth: > [success=end default=ignore] pam_systemd_home.so > Account-Type: Primary > Account: > [success=end default=ignore] pam_systemd_home.so > Session-Type: Additional > Session: > optional pam_systemd_home.so > Password-Type: Primary > Password: > [success=end default=ignore] pam_systemd_home.so > > > For some reason, this results in the following change being applied to > /etc/pam.d/common-password: > > -password [success=1 default=ignore] pam_unix.so obscure yescrypt > +password [success=2 default=ignore] pam_systemd_home.so > +password [success=1 default=ignore] pam_unix.so obscure use_authtok > try_first_pass yescrypt > > The first line is fine, but the second is the issue. > IE, use_authtok try_first_pass are added to pam_unix.so, which break > everything. Removing those manually fix things again. I have no idea > where they are coming from... PAM experts, any idea? The expectation is that when multiple password modules are stacked together via /usr/share/pam-configs, they will interoperate in a way that they will all share a single new password token. The 'try_first_pass use_authtok' arguments are injected by pam-auth-update in support of this. Presumably, in cases that a user does not have a systemd-home setup, the module does not prompt for a new password, thus causing pam_unix to fail because it expects the new password token to already be established in the pam stack (and will not prompt for it again). This behavior is not configurable through pam-auth-update; it is essential that the stack work this way to support password strength checking modules (if the password strength checker says the provided password fails the requirements and therefore does not set the token, it would be a bug for pam_unix (or other backend) to prompt again for a password and allow it to be set. pam_systemd_home would need to be modified to conform to the expected behavior (always prompt for old and new passwords even if not used) in order to be used with pam-auth-update. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: PGP signature