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

[Luca Boccassi]

On Mon, 27 May 2024 at 20:02, Steve Langasek <vorlon at 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