| Summary: | Drop chdir("/") in dbus-launch | ||
|---|---|---|---|
| Product: | dbus | Reporter: | David King <amigadave> |
| Component: | core | Assignee: | D-Bus Maintainers <dbus> |
| Status: | RESOLVED MOVED | QA Contact: | D-Bus Maintainers <dbus> |
| Severity: | normal | ||
| Priority: | medium | Keywords: | patch |
| Version: | git master | ||
| Hardware: | Other | ||
| OS: | All | ||
| See Also: | https://bugzilla.redhat.com/show_bug.cgi?id=1470310 | ||
| Whiteboard: | review? | ||
| i915 platform: | i915 features: | ||
| Attachments: |
drop the chdir("/") call from dbus-launch
use HOME as the working directory, if it is set |
||
Created attachment 140258 [details] [review] drop the chdir("/") call from dbus-launch dbus-launch definitely needs to chdir() to *somewhere* predictable that no user is going to want to delete or unmount, for the same reasons that well-behaved system services chdir("/") during daemonization. dbus-launch can be started in several ways:
* By a session manager like gnome-session
* By OS-distribution desktop infrastructure like Debian's /etc/X11/Xsession.d
(I think Red Hat has this under a different name involving xinit)
* Explicitly by a (possibly misguided) user
* Implicitly by libdbus (or GDBus) for X11 autolaunching
There's some background in <https://lists.debian.org/debian-devel/2016/08/msg00554.html>.
In the X11 autolaunching case it's a child of an arbitrarily-chosen user process (whichever one happens to be the first to try to use the session bus), which might be in an arbitrarily annoying directory.
Moving to the user's home directory as a sort of per-user equivalent of "/" would be a defensible change. I'm a little hesitant to make that change because dbus-launch is not a focus of development for Linux systems (the "user session" model with dbus-daemon --session managed by systemd --user seems like a better future), and dbus-launch has had its current behaviour for around 15 years...
(In reply to Simon McVittie from comment #2) >… > There's some background in > <https://lists.debian.org/debian-devel/2016/08/msg00554.html>. Thanks for the background! >… > Moving to the user's home directory as a sort of per-user equivalent of "/" > would be a defensible change. I'm a little hesitant to make that change > because dbus-launch is not a focus of development for Linux systems (the > "user session" model with dbus-daemon --session managed by systemd --user > seems like a better future), and dbus-launch has had its current behaviour > for around 15 years... My reasoning for this change would be that systemd --user has effectively changed the default working directory of dbus-daemon when used as a session bus to be the user's home directory. From that point of view, it makes sense that when dbus-launch is used in the same capacity, it sets the current working directory in the same (or a similar) way. I am not sure whether changing the default behaviour of dbus-launch to match the working directory of dbus-daemon launched by systemd --user makes sense, or if the behaviour should be opt-in. The working directory does not appear to be documented outside of the comment, but is common for persistent daemons, so is implied. Created attachment 140280 [details] [review] use HOME as the working directory, if it is set -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/dbus/dbus/issues/214. |
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.
In RHEL 7, Paul Gozart came across some unexpected behaviour in gedit when run as a regular user, where the save dialog used the root path ("/") as the default location. This was traced down by Ray Strode to gedit in newer RHEL 7 versions being launched by dbus activation (as most GNOME applications are, if they use GApplication), and the dbus-daemon used for the session bus in RHEL being launched with dbus-launch (by gnome-session, as systemd is not used as a user session manager in RHEL 7). There is a chdir("/") call in dbus-launch with the following justification: /* We chdir ("/") since we are persistent and daemon-like, and fork * again so dbus-launch can reap the parent. However, we don't * setsid() or close fd 0 because the idea is to remain attached * to the tty and the X server in order to kill the message bus * when the session ends. */ Arguably, this is not the best behaviour for a tool that is only used to run session buses, which are scoped to the lifetime of the user's session (with some exceptions, of course), and given the pervasive use of dbus-launch by session managers to start dbus-daemon as a session bus, I think that it is best to drop the chdir() call entirely.