| Summary: | pam_systemd injects libdbus into setuid programs | ||
|---|---|---|---|
| Product: | systemd | Reporter: | Colin Walters <walters> |
| Component: | general | Assignee: | systemd-bugs |
| Status: | RESOLVED FIXED | QA Contact: | systemd-bugs |
| Severity: | normal | ||
| Priority: | medium | CC: | smcv |
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
|
Description
Colin Walters
2012-09-18 18:04:47 UTC
(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.