Deleting "$HOME"/.identity Prevents Logging in to systemd-homed User Account

[jonathan-gruber-jg]

systemd version the issue has been seen with

255.6-1-arch

Used distribution

Arch Linux

Linux kernel version used

6.8.9-arch1-2

CPU architectures issue was seen on

x86_64

Component

systemd-homed

Expected behaviour you didn't see

Not sure if this is technically a bug, but it is certainly an annoyance. I am aware that this issue is somewhat a duplicate of issue #17688, but that issue seems to be stale, and my issue here is nonetheless different.

If the .identity file is missing from the home directory of a systemd-homed user account, or if that file is corrupted, systemd-homed should automatically regenerate it from the /var/lib/systemd/home/"$USER".identity file for the user. This regeneration could happen, e.g., when someone successfully logs in to the user account in question. If I am not mistaken, the only difference between "$HOME"/.identity and /var/lib/systemd/"$USER".identity is that /var/lib/systemd/"$USER".identity has some additional fields like "binding", "secret" , and "status", so "$HOME"/.identity could easily be regenerated by making a copy of /var/lib/systemd/"$USER".identity and removing those extra fields.

Unexpected behaviour you saw

I deleted the .identity file from the home directory of a systemd-homed user account. After rebooting the computer, I was unable to log in to the user account. Whenever I entered the password for the user account, it simply prompt for the password again. I am reasonably confident I entered the password correctly, and I got no messages saying that the password was incorrect, so I have reason to believe that my inability to log in to the account is not because of an incorrect password. I tried logging in from a tty and through SDDM.

I keep my root account locked, so the only way to log in to the root account is to do "sudo su" while already logged in to a normal account that is in the wheel group. Since I could not log in to the systemd-homed user, which was the only normal account on the operating system, I was basically locked out of logging in to any user account or using the system at all. I was only able to fix the problem by booting into a live ISO environment, manually copying the .identity file of the systemd-homed user from /var/lib/systemd/home/ to the user's home directory as .identity and manually editing the resulting .identity file to delete the "binding" and "status" fields (/var/lib/systemd/.identity had no "secret" field).

Steps to reproduce the problem

1. You need a systemd-homed user account in order to follow these steps. I recommend just creating a throwaway account that you can delete once you are done testing. I DO NOT recommend following these steps with your normal user account. If you choose to follow these steps with your normal user account, make sure you have some way of accessing your system afterwards in order to repair the damage, e.g. a live ISO environment that you can boot into from a flash drive.
2. Delete the "$HOME"/.identity file of this systemd-homed user.
3. Log out of the systemd-homed user account whose "$HOME"/.identity file you just deleted. When I did this on a systemd-homed user account, I am pretty sure I rebooted rather than simply logging out, but I see no reason why simply logging out would not suffice.
4. After rebooting or logging out, try to log back in to the systemd-homed user account in question. Observe that it will simply ask for the password again and again, no matter how many times you enter the password correctly. I observed this behavior while trying to log in through a tty and through SDDM.

Additional program output to the terminal or log subsystem illustrating the issue

No response

[AdrianVovk]

Yeah seems like something we can reasonably fix. I'll assign it to myself for now to eventually address it but if someone else wants to contribute the fix I'd appreciate it :)

[jonathan-gruber-jg]

I am not familiar with the workings of systemd-homed, but if under such a fix, "$HOME"/.identity would be automatically regenerated from /var/lib/systemd/home/"$USER".identity, would that not make the existence of "$HOME"/.identity redundant? If not, is there a specific use-case for systemd-homed that requires home directories to have a .identity file? Again, I am not familiar with the workings of systemd-homed.

[AdrianVovk]

Homed home dirs are supposed to be portable between machines. Different machines don't share /var. Hence ~/. identity is the canonical location of the user's settings, and /var as actually the backup (with machine-specific status information cached also)