On Mon, 27 May 2024 at 20:02, Steve Langasek <vor...@debian.org> wrote: > > 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.
pam_systemd_home returns PAM_USER_UNKNOWN when dealing with non-homed users, and I am quite sure that's entirely intentional, so that's a non-starter . So what I am hearing is that the pam-auth-update debianism can't really be used for this, and shipping a normal pam config file via dh_installpam is the way to go. I gave the following a quick test and seems to work: auth [success=2 default=ignore] pam_systemd_home.so @include common-auth account [success=2 default=ignore] pam_systemd_home.so @include common-account password [success=2 default=ignore] pam_systemd_home.so @include common-password session optional pam_systemd_home.so @include common-session-noninteractive session optional pam_systemd_home.so @include common-session
