Como o processo (sd-pam) se livra do 'pam_session_close ()' sem privilégios?

Question

É um erro?

link

            /* 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 link

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.

    

Answer 1

Sim. É um bug do systemd que foi aberto (no momento em que ele está escrevendo isso) nos últimos dois anos, que as pessoas do sistema, ignorando o relatório de bug, foram totalmente ignoradas.

Analisando Ben Collins em 2000 e a análise de David Z Maze do login do GDM recebendo pam_close_session() errado em 2001, provavelmente há uma falha de segurança no systemd, pronta para os curiosos descobrirem.

Leitura adicional

• David Herrmann (2015-09-25). PAMName = e unprameged pam_close_session () . bug systemd # 1350. GitHub.