See: https://bugs.freedesktop.org/show_bug.cgi?id=52202 Basically until this moment we had not spent a lot of time thinking about libdbus being used from a setuid program. Unfortunately, pam_systemd dynamically injects libdbus into anything that uses PAM, which is kind of a problem from this aspect. Now, libdbus will likely be "hardened" against such use, but I think any PAM module needs to be paranoid about this too. In this case, that means that pam_systemd should filter out any DBUS_ environment variables before initializing libdbus.
(In reply to comment #0) > 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] https://www.redhat.com/archives/pam-list/2013-January/msg00005.html
systemd git now uses libsystem-bus for all things dbus. The code in libsystem-bus uses secure_getenv() for accessing the environment everywhere, so I guess this bug can be closed.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.