Isn't the issue in this case caused not by suid, but by a daemon running as root reading files from a tmp dir? Seems like a socket-activated daemon wouldn't solve this specific case.
systemd-homed stores most of the user specific information in the home directory `~/.identity`, but since the file contents have to be signed the changes need to be done though a daemon, which is talked to via IPC (homectl does the talking to systemd-homed).
Comments
I would expect an unprivileged user to be able to change their own password. How else would that work?
Send a message to a socket-activated daemon running as a UID with write access to the password database.
Isn't the issue in this case caused not by suid, but by a daemon running as root reading files from a tmp dir? Seems like a socket-activated daemon wouldn't solve this specific case.
Windows way is to have a privileged service which the non-privileged user application talks to over sockets or similar.
systemd-homed stores most of the user specific information in the home directory `~/.identity`, but since the file contents have to be signed the changes need to be done though a daemon, which is talked to via IPC (homectl does the talking to systemd-homed).