Bug#1056166: systemd-homed: `passwd` fails

[Steve Langasek]

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/
slangasek at ubuntu.com                                     vorlon at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20240527/fee428ad/attachment.sig>