Bug#1056166: systemd-homed: `passwd` fails
On Mon, 27 May 2024 at 20:02, Steve Langasek 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: > > optionalpam_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
Bug#1056166: systemd-homed: `passwd` fails
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: > optionalpam_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
Bug#1056166: systemd-homed: `passwd` fails
On Mon, 27 May 2024 at 01:38, Sam Hartman wrote: > > > "Luca" == Luca Boccassi writes: > > Luca> Ah thanks for the pointer to the file, I had missed that > Luca> somehow in the first reply. I see it now: the pam-config for > Luca> unix.so assumes that if something runs before then everything > Luca> is done already. Unfortunately that assumption is wrong. I'll > Luca> see if I can just hack it and monkey patch common-password in > Luca> the postinst to fix it up for now, as I assume this is some > Luca> load-bearing assumption. > > I think if you want to play with it and modify common-password, that's > fine. > > I do not think that's appropriate for testing though. > > I'm fairly uncomfortable with a package other than pam touching > common-password in postinst other than through pam-auth-update. > It's fairly unlikely to work and likely to cause problems on upgrade. > I'd be much happier with (at least for now) simply not auto-configuring > systemd-home and leaving that to the sysadmin. > I appreciate that is not what you want to hear, but: > > 1) I believe that package a modifying a configuration file of package b > without cooperation of package b is a clear policy violation. > > 2) common-password is a configuration file of pam. > > 3) I'd like to understand the situation muchd better and especially why > you need to be account-type:primary. > I suspect we're going to need to have changes to pam-auth-update. It is a horrible hack, no doubt about that, and will require reconfigures/reinstalls every now and then - however, it fixes the problem on install, which is directly solving my problem, as fresh testing images are broken and I need them working for my development/test workflows, so I'll still add it. It's an optional package with no reverse depends, so not really a problem for anybody who doesn't use it. Once there is a better solution, I will happily switch over. Thanks for the hints that helped figure this out, it did not occur to me to look into the other config.
Bug#1056166: systemd-homed: `passwd` fails
> "Luca" == Luca Boccassi writes: Luca> Ah thanks for the pointer to the file, I had missed that Luca> somehow in the first reply. I see it now: the pam-config for Luca> unix.so assumes that if something runs before then everything Luca> is done already. Unfortunately that assumption is wrong. I'll Luca> see if I can just hack it and monkey patch common-password in Luca> the postinst to fix it up for now, as I assume this is some Luca> load-bearing assumption. I think if you want to play with it and modify common-password, that's fine. I do not think that's appropriate for testing though. I'm fairly uncomfortable with a package other than pam touching common-password in postinst other than through pam-auth-update. It's fairly unlikely to work and likely to cause problems on upgrade. I'd be much happier with (at least for now) simply not auto-configuring systemd-home and leaving that to the sysadmin. I appreciate that is not what you want to hear, but: 1) I believe that package a modifying a configuration file of package b without cooperation of package b is a clear policy violation. 2) common-password is a configuration file of pam. 3) I'd like to understand the situation muchd better and especially why you need to be account-type:primary. I suspect we're going to need to have changes to pam-auth-update.
Bug#1056166: systemd-homed: `passwd` fails
On Mon, 27 May 2024 at 00:30, Sam Hartman wrote: > > > "Luca" == Luca Boccassi writes: > > Luca> > https://www.freedesktop.org/software/systemd/man/latest/pam_systemd_home.html > > It's going to be a long time (a couple of weeks) before I have cycles to > actually look at systemd-home rather than to answer questions with my > pam hat on without looking at your application. > The limits issue you wrote to me about yesterday is ahead in the queue, > as likely is a new version of krb5. > > Luca> Any idea where use_authtok try_first_pass could be coming > Luca> from? I don't see them defined anywhere in the pam config I am > Luca> shipping, so I have no idea why pam-auth-update is adding > Luca> them. > > I gave you pointers where to look for these: /usr/share/pam-config/unix > This is complex enough that someone who both has a good understanding of > pam and systemd-home is going to need to get involved. > I can talk about the broader pam context, and some issues people have > run into in the past, but someone needs to have both systemd-home and > pam in their heads to definitively decide what systemd-home wants out of > pam. > That's not going to be me any time soon. Ah thanks for the pointer to the file, I had missed that somehow in the first reply. I see it now: the pam-config for unix.so assumes that if something runs before then everything is done already. Unfortunately that assumption is wrong. I'll see if I can just hack it and monkey patch common-password in the postinst to fix it up for now, as I assume this is some load-bearing assumption.
Bug#1056166: systemd-homed: `passwd` fails
> "Luca" == Luca Boccassi writes: Luca> https://www.freedesktop.org/software/systemd/man/latest/pam_systemd_home.html It's going to be a long time (a couple of weeks) before I have cycles to actually look at systemd-home rather than to answer questions with my pam hat on without looking at your application. The limits issue you wrote to me about yesterday is ahead in the queue, as likely is a new version of krb5. Luca> Any idea where use_authtok try_first_pass could be coming Luca> from? I don't see them defined anywhere in the pam config I am Luca> shipping, so I have no idea why pam-auth-update is adding Luca> them. I gave you pointers where to look for these: /usr/share/pam-config/unix This is complex enough that someone who both has a good understanding of pam and systemd-home is going to need to get involved. I can talk about the broader pam context, and some issues people have run into in the past, but someone needs to have both systemd-home and pam in their heads to definitively decide what systemd-home wants out of pam. That's not going to be me any time soon.
Bug#1056166: systemd-homed: `passwd` fails
On Sun, 26 May 2024 at 21:46, Sam Hartman wrote: > > > Hi. > I'm not really swapped in on Debian this weekend; dealing with a > transition for day job. > > But quick thoughts. > > I'm surprised that systemd-home is a pam auth module. > That is, I wouldn't expect systemd-home to be able to decide whether you > have presented valid credentials to log in. > It may be that it has an account entry point, but it's auth entry point > is trivial. > > pam-auth-update assumes that you don't want to reenter a password. > So, it assumes the first module in the stack will take a password and > then we will reuse that. > > Similarly for password, you don't want to for example change the ldap > and local passwords to different values. > > > compare the auth vs auth-initial password vs password-initial lines in > /usr/share/pam-configs/unix. > > > Will systemd-home work with an auth-type of additional rather than > primary? You are asking difficult questions I'm afraid, I don't really know very well how PAM works to be able to answer. What I can tell you is that users and passwords are definitely defined in homed, as the purpose is to manage users and homes. Here's the manpage: https://www.freedesktop.org/software/systemd/man/latest/pam_systemd_home.html Any idea where use_authtok try_first_pass could be coming from? I don't see them defined anywhere in the pam config I am shipping, so I have no idea why pam-auth-update is adding them.
Bug#1056166: systemd-homed: `passwd` fails
Hi. I'm not really swapped in on Debian this weekend; dealing with a transition for day job. But quick thoughts. I'm surprised that systemd-home is a pam auth module. That is, I wouldn't expect systemd-home to be able to decide whether you have presented valid credentials to log in. It may be that it has an account entry point, but it's auth entry point is trivial. pam-auth-update assumes that you don't want to reenter a password. So, it assumes the first module in the stack will take a password and then we will reuse that. Similarly for password, you don't want to for example change the ldap and local passwords to different values. compare the auth vs auth-initial password vs password-initial lines in /usr/share/pam-configs/unix. Will systemd-home work with an auth-type of additional rather than primary?
Bug#1056166: systemd-homed: `passwd` fails
Control: tags -1 help On Sun, 19 Nov 2023 23:48:46 +0100 Alexander Bochmann wrote: > Package: systemd-homed > Version: 254.5-1~bpo12+2 > Followup-For: Bug #1056166 > > Hello, > > I can confirm this problem still exists in bookworm and > bookworm-backports: > > As soon as the Debian systemd-homed PAM configuration is activated > by pam-auth-update, it's not possible to change passwords of > users that come from /etc/passwd anymore. > > This seems to be due to a PAM misconfiguration. I don't understand > enough of the Debian PAM setup to say why it doesn't work, but > I tried replacing the rules with alternatives that I copied from > an openSUSE Tumbleweed install, and using those it's possible to > change details on users both from /etc/passwd and systemd-homed. 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: optionalpam_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? -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1056166: systemd-homed: `passwd` fails
Package: systemd-homed Version: 254.5-1~bpo12+2 Followup-For: Bug #1056166 Hello, I can confirm this problem still exists in bookworm and bookworm-backports: As soon as the Debian systemd-homed PAM configuration is activated by pam-auth-update, it's not possible to change passwords of users that come from /etc/passwd anymore. This seems to be due to a PAM misconfiguration. I don't understand enough of the Debian PAM setup to say why it doesn't work, but I tried replacing the rules with alternatives that I copied from an openSUSE Tumbleweed install, and using those it's possible to change details on users both from /etc/passwd and systemd-homed. Alex. -- System Information: Debian Release: 12.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: arm64 (aarch64) Foreign Architectures: armhf Kernel: Linux 6.1.0-rpi6-rpi-v8 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_CRAP Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages systemd-homed depends on: ii init-system-helpers 1.65.2 ii libblkid12.38.1-5+b1 ii libc62.36-9+rpt2+deb12u3 ii libcap2 1:2.66-4 ii libfdisk12.38.1-5+b1 ii libp11-kit0 0.24.1-2 ii libpam-runtime 1.5.2-6+rpt2+deb12u1 ii libpam0g 1.5.2-6+rpt2+deb12u1 ii libssl3 3.0.11-1~deb12u2+rpt1 ii libsystemd-shared254.5-1~bpo12+2 ii systemd 254.5-1~bpo12+2 ii systemd-userdbd 254.5-1~bpo12+2 systemd-homed recommends no packages. systemd-homed suggests no packages. -- no debconf information
Bug#1056166: systemd-homed: `passwd` fails
Control: found -1 254.5-1 This is not a regression of v255, as v254 shows the same behaviour. Marking accordingly. OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1056166: systemd-homed: `passwd` fails
Am 18.11.23 um 03:25 schrieb Jack Pearson: $ apt install systemd-homed $ passwd passwd: Authentication token manipulation error Installing systemd-homed changes the PAM configuration of common-passwd: # here are the per-package modules (the "Primary" block) -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 Enabling some debug flags yields Nov 18 05:39:03 debian passwd[6463]: pam_systemd_home(passwd:chauthtok): pam-systemd-homed account management Nov 18 05:39:03 debian passwd[6463]: pam_systemd_home(passwd:chauthtok): Not a user managed by systemd-homed: No home for user michael known Nov 18 05:39:03 debian passwd[6463]: pam_unix(passwd:chauthtok): username [michael] obtained Nov 18 05:39:06 debian passwd[6463]: pam_systemd_home(passwd:chauthtok): pam-systemd-homed account management Nov 18 05:39:06 debian passwd[6463]: pam_unix(passwd:chauthtok): username [michael] obtained Nov 18 05:39:06 debian passwd[6463]: pam_unix(passwd:chauthtok): password - new password not obtained I'm not really familiar with PAM though, so no idea how to fix this. OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1056166: systemd-homed: `passwd` fails
Package: systemd-homed Version: 255~rc2-1 Severity: important Dear Maintainer, In a minimal Debian installation, `systemd-homed` breaks `passwd`. Just run these commands: ``` $ sudo -sE $ debootstrap unstable unstable-dir $ chroot unstable-dir $ apt install systemd-homed $ passwd passwd: Authentication token manipulation error passwd: password unchanged ``` I'm certain this isn't a quirk of the chroot installation, I first found this issue on Raspbian installed on actual hardware, version bookworm. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.5.0-4-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=C.UTF-8 (charmap=locale: Cannot set LC_MESSAGES to default locale: No such file or directory locale: Cannot set LC_ALL to default locale: No such file or directory UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: unable to detect Versions of packages systemd-homed depends on: ii init-system-helpers 1.65.2 ii libblkid12.39.2-6 ii libc62.37-12 ii libcap2 1:2.66-4 ii libfdisk12.39.2-6 ii libpam-runtime 1.5.2-9.1 ii libpam0g 1.5.2-9.1 ii libssl3 3.0.12-2 ii libsystemd-shared255~rc2-1 ii systemd 255~rc2-1 ii systemd-userdbd 255~rc2-1 systemd-homed recommends no packages. systemd-homed suggests no packages. -- debconf information excluded
