<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW --- - pam_systemd injects libdbus into setuid programs" href="https://bugs.freedesktop.org/show_bug.cgi?id=55062#c1">Comment # 1</a> on <a class="bz_bug_link bz_status_NEW " title="NEW --- - pam_systemd injects libdbus into setuid programs" href="https://bugs.freedesktop.org/show_bug.cgi?id=55062">bug 55062</a> from <a class="email" href="mailto:simon.mcvittie@collabora.co.uk" title="Simon McVittie <simon.mcvittie@collabora.co.uk>"> Simon McVittie</a> <pre>(In reply to <a href="show_bug.cgi?id=55062#c0">comment #0</a>) > In this case, that means that pam_systemd should filter out any DBUS_ > environment variables before initializing libdbus. I don't think that makes sense. Environment variables are global state: a "mere plugin" shouldn't be messing with global state. I've asked the PAM maintainers[1] to clarify their policy on who is responsible for avoiding "bad" environment variables, but not received any response so far. One thing that pam_systemd (and other plugins in this situation) could usefully do would be to hard-code the address to connect to: instead of using dbus_bus_get_private(), it could use dbus_connection_open_private() and dbus_bus_register(). That would avoid looking up DBUS_SYSTEM_BUS_ADDRESS, at least. I think it would be reasonable to say that pam_systemd doesn't support systems where the system bus isn't /var/run/dbus/system_bus_socket. [1] <a href="https://www.redhat.com/archives/pam-list/2013-January/msg00005.html">https://www.redhat.com/archives/pam-list/2013-January/msg00005.html</a></pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> <li>You are the assignee for the bug.</li> </ul> </body> </html>