9

Is it a bug?

https://github.com/systemd/systemd/blob/v234/src/core/execute.c#L1126

            /* Drop privileges - we don't need any to pam_close_session
             * and this will make PR_SET_PDEATHSIG work in most cases.
             * If this fails, ignore the error - but expect sd-pam threads
             * to fail to exit normally */

Compare http://jdebp.eu./FGA/dont-abuse-su-for-dropping-privileges.html

The new implementation called fork() and only dropped privileges in the child, retaining a privileged account parent process that could call the PAM "user session" cleanup function once the child exited. (See contemporary accounts such as this one from Ben Collins.) An initial implementation where the PAM "user session" was opened in the parent process and closed in the child was found to be faulty, with bugs such as Debian Bug #195048, Debian Bug #580434, and Debian Bug #599731 a.k.a. Gentoo Bug #246813 because the unprivileged child did not have the access rights to undo all of the session setup that opening the session did in the privileged parent.

For the next decade, bits and pieces kept popping up related to PAM and su. In 2004, for example, there was a problem with the SELinux pluggable authentication module.

sourcejedi
  • 50,249

1 Answers1

9

Yes. It is a systemd bug that has been open (at the time of writing this) for the last two years in fact, which systemd people have, going by the bug report, entirely ignored.

Going by Ben Collins' analysis back in 2000 and David Z Maze's analysis of GDM login getting pam_close_session() wrong in 2001, there is probably a security hole in systemd there, ready for the curious to discover.

Further reading

JdeBP
  • 68,745