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

[Jack Pearson]

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 libblkid1 2.39.2-6
ii libc6 2.37-12
ii libcap2 1:2.66-4
ii libfdisk1 2.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-shared 255~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

[Alexander Bochmann]

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 libblkid1 2.38.1-5+b1
ii libc6 2.36-9+rpt2+deb12u3
ii libcap2 1:2.66-4
ii libfdisk1 2.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-shared 254.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

[Luca Boccassi]

Control: tags -1 help

On Sun, 19 Nov 2023 23:48:46 +0100 Alexander Bochmann

Post by Jack Pearson
Package: systemd-homed
Version: 254.5-1~bpo12+2
Followup-For: Bug #1056166
Hello,
I can confirm this problem still exists in bookworm and
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:
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?

[Sam Hartman]

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?

[Luca Boccassi]

Post by Sam Hartman
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.

[Sam Hartman]

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.

[Steve Langasek]

Post by Luca Boccassi
Control: tags -1 help
# cat /usr/share/pam-configs/systemd-homed
Name: Enable user management by systemd-homed
Default: yes
Priority: 257
Auth-Type: Primary
[success=end default=ignore] pam_systemd_home.so
Account-Type: Primary
[success=end default=ignore] pam_systemd_home.so
Session-Type: Additional
optional pam_systemd_home.so
Password-Type: Primary
[success=end default=ignore] pam_systemd_home.so
For some reason, this results in the following change being applied to
-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.

[Luca Boccassi]

Post by Steve Langasek

Post by Luca Boccassi
Control: tags -1 help
# cat /usr/share/pam-configs/systemd-homed
Name: Enable user management by systemd-homed
Default: yes
Priority: 257
Auth-Type: Primary
[success=end default=ignore] pam_systemd_home.so
Account-Type: Primary
[success=end default=ignore] pam_systemd_home.so
Session-Type: Additional
optional pam_systemd_home.so
Password-Type: Primary
[success=end default=ignore] pam_systemd_home.so
For some reason, this results in the following change being applied to
-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

[Luca Boccassi]

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.

[Sam Hartman]

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.

[Luca Boccassi]

Post by Sam Hartman
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.
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.

[Anthony Bourguignon]

Source: systemd
Source-Version: 256~rc3-3
We believe that the bug you reported is fixed in the latest version of
systemd, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed.  If you
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Format: 1.8
Date: Tue, 28 May 2024 00:07:57 +0100
Source: systemd
Architecture: source
Version: 256~rc3-3
Distribution: unstable
Urgency: medium
Closes: 825438 851314 913061 966621 1029152 1056166 1056564
  systemd (256~rc3-3) unstable; urgency=medium
  .
    [ Zbigniew Jędrzejewski-Szmek ]
    * tests/boot-and-services: don't wait for systemd-tmpfiles-clean.service
      to finish. It's a oneshot service, so the 'start' call above is
      effectively synchronous.
    * test/boot-and-services: use pidof instead of ps -C
  .
    [ Chris Hofstaedtler ]
    * autopkgtest: install open-iscsi and tgt for upstream suite
  .
    [ Gioele Barabucci ]
    * d/libnss-mymachines.nss: Install before `resolve` and `dns`. Installing
      `mymachines` before `dns` and `resolve` (whatever comes first) is
      suggested in the manpage. It also avoids leaking information about
      local machines to the DNS resolver. (Closes: #825438, #851314)
    * d/libnss-myhostname.nss: Install after `files`
  .
    [ Luca Boccassi ]
    * Drop /bin/systemd legacy symlink. The systemd binary should not be in
      the default PATH. This symlink was created due to some old
      documentation (long since corrected) suggesting to use
      init=/bin/systemd to test switching to systemd. (Closes: #913061)

Hi,

Since 256~rc3-3, I can’t login anymore with my homed user. How it happened : I logged in with GDM to
my Gnome session. I made the updates, including the systemd-homed version 256~rc3-3. When I locked
my screen, I was unable to unlock it. The password was refused. So I restarted the computer and I
was unable to log back onto it.

I tried with Gnome, ssh, su (as root), nothing worked.

I think your modifications completely broke systemd-homed authentification. The system didn’t
recognize the user at all :
2024-05-28T11:42:29.266019+02:00 **redacted** unix_chkpwd[2223]: check pass; user unknown
2024-05-28T11:44:17.113169+02:00 **redacted** unix_chkpwd[2351]: could not obtain user info
(**redacted**)

I rsynced the /etc/pam.d/common* files from another computer, deleted the systemd-homed file in the
same directory, and everything is back to normal.

Thanks

[Luca Boccassi]

On Tue, 28 May 2024 13:09:53 +0200 Anthony Bourguignon

Hi,
Since 256~rc3-3, I can’t login anymore with my homed user. How it
happened : I logged in with GDM to
my Gnome session. I made the updates, including the systemd-homed
version 256~rc3-3. When I locked
my screen, I was unable to unlock it. The password was refused. So I
restarted the computer and I
was unable to log back onto it.
I tried with Gnome, ssh, su (as root), nothing worked.
I think your modifications completely broke systemd-homed
authentification. The system didn’t
2024-05-28T11:42:29.266019+02:00 **redacted** unix_chkpwd[2223]: check pass; user unknown
2024-05-28T11:44:17.113169+02:00 **redacted** unix_chkpwd[2351]: could not obtain user info
(**redacted**)
I rsynced the /etc/pam.d/common* files from another computer, deleted
the systemd-homed file in the
same directory, and everything is back to normal.

uff I tested it from a TTY rather than GNOME and it worked. Does it
work from the console for you?

[Anthony Bourguignon]

Post by Luca Boccassi
On Tue, 28 May 2024 13:09:53 +0200 Anthony Bourguignon

Post by Anthony Bourguignon
Hi,
Since 256~rc3-3, I can’t login anymore with my homed user. How it
happened : I logged in with GDM to
my Gnome session. I made the updates, including the systemd-homed
version 256~rc3-3. When I locked
my screen, I was unable to unlock it. The password was refused. So I
restarted the computer and I
was unable to log back onto it.
I tried with Gnome, ssh, su (as root), nothing worked.
I think your modifications completely broke systemd-homed
authentification. The system didn’t
check pass; user unknown
could not obtain user info
(**redacted**)
I rsynced the /etc/pam.d/common* files from another computer, deleted
the systemd-homed file in the
same directory, and everything is back to normal.

uff I tested it from a TTY rather than GNOME and it worked. Does it
work from the console for you?

I’ve tried with another PC. From the console, I can log in but the session closes directly. If, from
root, I try "su - username", I’ve got the message : "called without reference on home taken, can’t
operate" and the session doesn’t open.

If I try to log in Gnome from GDM, it works, but it seems the home directory is not uncrypted and
mounted. So my session is clear and I can’t launch any app.

But I don’t understand why I don’t have the same behavior as the other PC.

[Luca Boccassi]

Post by Luca Boccassi
On Tue, 28 May 2024 13:09:53 +0200 Anthony Bourguignon

Post by Anthony Bourguignon
Hi,
Since 256~rc3-3, I can’t login anymore with my homed user. How it
happened : I logged in with GDM to
my Gnome session. I made the updates, including the systemd-homed
version 256~rc3-3. When I locked
my screen, I was unable to unlock it. The password was refused. So I
restarted the computer and I
was unable to log back onto it.
I tried with Gnome, ssh, su (as root), nothing worked.
I think your modifications completely broke systemd-homed
authentification. The system didn’t
check pass; user unknown
could not obtain user info
(**redacted**)
I rsynced the /etc/pam.d/common* files from another computer, deleted
the systemd-homed file in the
same directory, and everything is back to normal.

uff I tested it from a TTY rather than GNOME and it worked. Does it
work from the console for you?

I’ve tried with another PC. From the console, I can log in but the session closes directly. If, from
root, I try "su - username", I’ve got the message : "called without reference on home taken, can’t
operate" and the session doesn’t open.
If I try to log in Gnome from GDM, it works, but it seems the home directory is not uncrypted and
mounted. So my session is clear and I can’t launch any app.
But I don’t understand why I don’t have the same behavior as the other PC.

Ok, activation of the homed entry was borked then - what's the
situation in your /etc/pam.d? Do you still have systemd_home
references outside of its own config module?

[Anthony Bourguignon]

Post by Luca Boccassi

Post by Luca Boccassi
On Tue, 28 May 2024 13:09:53 +0200 Anthony Bourguignon

Post by Anthony Bourguignon
Hi,
Since 256~rc3-3, I can’t login anymore with my homed user. How it
happened : I logged in with GDM to
my Gnome session. I made the updates, including the systemd-homed
version 256~rc3-3. When I locked
my screen, I was unable to unlock it. The password was refused. So I
restarted the computer and I
was unable to log back onto it.
I tried with Gnome, ssh, su (as root), nothing worked.
I think your modifications completely broke systemd-homed
authentification. The system didn’t
check pass; user unknown
could not obtain user info
(**redacted**)
I rsynced the /etc/pam.d/common* files from another computer, deleted
the systemd-homed file in the
same directory, and everything is back to normal.

uff I tested it from a TTY rather than GNOME and it worked. Does it
work from the console for you?

I’ve tried with another PC. From the console, I can log in but the session closes directly. If,
from
root, I try "su - username", I’ve got the message : "called without reference on home taken,
can’t
operate" and the session doesn’t open.
If I try to log in Gnome from GDM, it works, but it seems the home directory is not uncrypted
and
mounted. So my session is clear and I can’t launch any app.
But I don’t understand why I don’t have the same behavior as the other PC.

Ok, activation of the homed entry was borked then - what's the
situation in your /etc/pam.d? Do you still have systemd_home
references outside of its own config module?

The only references to systemd_home are in /etc/pam.d/systemd-homed . Nothing in the common* files.

[Luca Boccassi]

Post by Anthony Bourguignon

Post by Luca Boccassi

Post by Luca Boccassi
On Tue, 28 May 2024 13:09:53 +0200 Anthony Bourguignon

Post by Anthony Bourguignon
Hi,
Since 256~rc3-3, I can’t login anymore with my homed user. How it
happened : I logged in with GDM to
my Gnome session. I made the updates, including the systemd-homed
version 256~rc3-3. When I locked
my screen, I was unable to unlock it. The password was refused. So I
restarted the computer and I
was unable to log back onto it.
I tried with Gnome, ssh, su (as root), nothing worked.
I think your modifications completely broke systemd-homed
authentification. The system didn’t
check pass; user unknown
could not obtain user info
(**redacted**)
I rsynced the /etc/pam.d/common* files from another computer, deleted
the systemd-homed file in the
same directory, and everything is back to normal.

uff I tested it from a TTY rather than GNOME and it worked. Does it
work from the console for you?

I’ve tried with another PC. From the console, I can log in but the session closes directly. If,
from
root, I try "su - username", I’ve got the message : "called without reference on home taken,
can’t
operate" and the session doesn’t open.
If I try to log in Gnome from GDM, it works, but it seems the home directory is not uncrypted
and
mounted. So my session is clear and I can’t launch any app.
But I don’t understand why I don’t have the same behavior as the other PC.

Ok, activation of the homed entry was borked then - what's the
situation in your /etc/pam.d? Do you still have systemd_home
references outside of its own config module?

The only references to systemd_home are in /etc/pam.d/systemd-homed . Nothing in the common* files.

Ok - I'll try to reproduce later tonight

[Luca Boccassi]

Post by Luca Boccassi

Post by Anthony Bourguignon

Post by Luca Boccassi

Post by Luca Boccassi
On Tue, 28 May 2024 13:09:53 +0200 Anthony Bourguignon

Post by Anthony Bourguignon
Hi,
Since 256~rc3-3, I can’t login anymore with my homed user. How it
happened : I logged in with GDM to
my Gnome session. I made the updates, including the systemd-homed
version 256~rc3-3. When I locked
my screen, I was unable to unlock it. The password was refused. So I
restarted the computer and I
was unable to log back onto it.
I tried with Gnome, ssh, su (as root), nothing worked.
I think your modifications completely broke systemd-homed
authentification. The system didn’t
check pass; user unknown
could not obtain user info
(**redacted**)
I rsynced the /etc/pam.d/common* files from another computer, deleted
the systemd-homed file in the
same directory, and everything is back to normal.

uff I tested it from a TTY rather than GNOME and it worked. Does it
work from the console for you?

I’ve tried with another PC. From the console, I can log in but the session closes directly. If,
from
root, I try "su - username", I’ve got the message : "called without reference on home taken,
can’t
operate" and the session doesn’t open.
If I try to log in Gnome from GDM, it works, but it seems the home directory is not uncrypted
and
mounted. So my session is clear and I can’t launch any app.
But I don’t understand why I don’t have the same behavior as the other PC.

Ok, activation of the homed entry was borked then - what's the
situation in your /etc/pam.d? Do you still have systemd_home
references outside of its own config module?

The only references to systemd_home are in /etc/pam.d/systemd-homed . Nothing in the common* files.

Ok - I'll try to reproduce later tonight

In the meanwhile, if you are feeling adventurous and want to mess with
the pam config, if you find a way to make it happy let me know

[Luca Boccassi]

Post by Luca Boccassi

Post by Luca Boccassi

Post by Anthony Bourguignon

Post by Luca Boccassi

Post by Luca Boccassi
On Tue, 28 May 2024 13:09:53 +0200 Anthony Bourguignon

Post by Anthony Bourguignon
Hi,
Since 256~rc3-3, I can’t login anymore with my homed user. How it
happened : I logged in with GDM to
my Gnome session. I made the updates, including the systemd-homed
version 256~rc3-3. When I locked
my screen, I was unable to unlock it. The password was refused. So I
restarted the computer and I
was unable to log back onto it.
I tried with Gnome, ssh, su (as root), nothing worked.
I think your modifications completely broke systemd-homed
authentification. The system didn’t
check pass; user unknown
could not obtain user info
(**redacted**)
I rsynced the /etc/pam.d/common* files from another computer, deleted
the systemd-homed file in the
same directory, and everything is back to normal.

uff I tested it from a TTY rather than GNOME and it worked. Does it
work from the console for you?

I’ve tried with another PC. From the console, I can log in but the session closes directly. If,
from
root, I try "su - username", I’ve got the message : "called without reference on home taken,
can’t
operate" and the session doesn’t open.
If I try to log in Gnome from GDM, it works, but it seems the home directory is not uncrypted
and
mounted. So my session is clear and I can’t launch any app.
But I don’t understand why I don’t have the same behavior as the other PC.

Ok, activation of the homed entry was borked then - what's the
situation in your /etc/pam.d? Do you still have systemd_home
references outside of its own config module?

The only references to systemd_home are in /etc/pam.d/systemd-homed . Nothing in the common* files.

Ok - I'll try to reproduce later tonight

In the meanwhile, if you are feeling adventurous and want to mess with
the pam config, if you find a way to make it happy let me know

256~rc3-5 should fix it - turns out standalone modules cannot work in
Debian, so it's back to pam-auth-update + monkey patching