Dominick Grift <dominick.gr...@defensec.nl> writes: > Dominick Grift <dominick.gr...@defensec.nl> writes: > >> Michal Koutný <mkou...@suse.com> writes: >> >>> On Tue, Jul 22, 2025 at 06:21:28PM +0200, Dominick Grift >>> <dominick.gr...@defensec.nl> wrote: >>>> To be clear: >>>> >>>> 1. currently sd-pam does not always run as root >>> >>> Ah, good. >>> >>>> 2. when sd-pam does not run as root then it lacks permission needed to >>>> do its job for some pam modules >>> >>> Such modules are frowned upon >>> https://github.com/systemd/systemd/issues/8598#issuecomment-1883471227 >> >> That is the answer I was looking for. It think it is unreasonable for >> systemd to unilateraly decide to break these modules. This could >> introduce security issues. Not to mention that systemd seemingly decides >> its exceptional compared to other login programs. >> > > The PAM module I am refering to is pam_selinux. It resets the terminal > context when the session closes. However since the terminal is then > owned by root and sd-pam runs as an unprivileged user it cannot reset > it. Leaving it in a bad state. > > pam_close_session.3 states: > > It should be noted that the effective uid, geteuid(2). of the > application should be of sufficient privilege to perform such > tasks as unmounting the user's home directory for example. >
I believe that the issue was triggered by a bug so my apologies for jumping the gun. systemctl --user --machine=user@.host ... should not be using /etc/pam.d/login (PAMName=login) I believe because it uses systemd-stdio-bridge and it cannot/shouldnt be used with a pty. It think that a custom /etc/pam.d/systemd-stdio-bridge (PAMName=systemd-stdio-bridge) might be in order here so that we can call pam_selinux with nottys. Other PAM modules might also suffer from this. I noticed that pam_wtmpdb was unhappy too for some reason. >>> >>> Michal >>> -- gpg --locate-keys dominick.gr...@defensec.nl (wkd) Key fingerprint = FCD2 3660 5D6B 9D27 7FC6 E0FF DA7E 521F 10F6 4098 Dominick Grift Mastodon: @kcini...@defensec.nl