Support dbus runtime relocation

Created attachment 127303
proposed patch

It would be nice if DBus added support for a runtime relocatable root in Unix. i.e. at runtime, be able to be run from /opt/dbus/ or some such, without having that be a compile-time prefix.

I notice the Windows version has some basic support for this. Detecting its installation directory and treating paths as relative to that.

My specific use case is testing a snap [1] of a full desktop environment. This bundled in dbus and session services and all sorts of things. The session DBus was trying to activate services with their compile-time hardcoded paths and not finding them.

And I bet similar use cases exist.

The plumbing already exists to fix those paths up, thanks to the Windows support.

So I threw together a patch for the Unix side of things, to listen to the new variable DBUS_ROOT. If you prefer a different env name, let me know.

[1] http://snapcraft.io/

(In reply to Michael Terry from comment #0)
> So I threw together a patch for the Unix side of things, to listen to the
> new variable DBUS_ROOT.

libdbus and dbus-daemon are security-sensitive code, and in some configurations the environment is attacker-controlled. Please don't rush into this.

Comment on attachment 127303
proposed patch

Review of attachment 127303:
-----------------------------------------------------------------

For the session bus, it would seem reasonable to search XDG_DATA_DIRS according to the basedir spec (<https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html>). I'd rather do that than invent a new environment variable.

I'm somewhat sceptical about the correctness of a Snap app-container running its own dbus-daemon - a contained app doesn't sound a lot like a login session to me (<https://dbus.freedesktop.org/doc/dbus-specification.html#message-bus-types>), and this is pretty much the opposite of the direction that the "user-session" work has gone in (<https://lists.freedesktop.org/archives/systemd-devel/2015-January/027711.html>).

However, relocating a dbus-daemon with XDG_DATA_DIRS seems potentially useful for regression testing or whatever (which is also the intended purpose of most of the environment variables that Snap app-containers (ab)use to pretend to be a namespace, AIUI).

---

What is your use case for relocating the system bus?

The system bus is a bus for the system. Running a separate system bus in a container seems deeply inappropriate, unless the container is as close to whole-system as things like lxc and Docker, in which case the chroot-like environment will do the right thing anyway.

(In reply to Simon McVittie from comment #2)
> For the session bus, it would seem reasonable to search XDG_DATA_DIRS
> according to the basedir spec
> (<https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.
> html>). I'd rather do that than invent a new environment variable.

What I mean here is: take the logic we use for <standard_session_servicedirs/>, which I assume you're basically happy with because you don't seem to have patched it, and apply it to finding ${datadir}/dbus-1/session.conf (taking the first one and ignoring any that it "shadows" seems reasonable).

We implement <standard_session_servicedirs/> by behaving as though our compile-time @DATADIR@ had been appended to XDG_DATA_DIRS; the same would make sense for ${datadir}/dbus-1/session.conf.

Thank you for looking at this!

> Please don't rush into this.

Agreed. I wanted to check with you folks before I actually did anything on the Ubuntu side.

> What is your use case for relocating the system bus?

I don't have one. I was just trying to be consistent with the other changes. I'm happy to drop those bits.

> I'm somewhat sceptical about the correctness of a Snap app-container running its own dbus-daemon - a contained app doesn't sound a lot like a login session to me

In most cases, yes, that wouldn't be a normal thing to do. But this is a bit of a special "fat" snap for an entire desktop environment (unity8 is what I'm testing now, but I don't see why one couldn't also snap up a GNOME or KDE session).

> We implement <standard_session_servicedirs/> by behaving as though our compile-time @DATADIR@ had been appended to XDG_DATA_DIRS; the same would make sense for ${datadir}/dbus-1/session.conf.

So the serviceconf-discovery aspects of my patch were merely me trying to make the Unix side of things be consistent with what the Windows side of things does, now that _dbus_replace_install_prefix was no longer a no-op.

But adjusting XDG_DATA_DIRS is enough for my purposes there. My major goal with this patch was actually to make relocating of activated services work. I think I buried that lede.

In activation.c, _dbus_replace_install_prefix is called on the Exec= line found in the service desktop file.

Consider this snap I'm trying to make, with session dbus and installed session services. One such service might have an Exec line like Exec=/usr/bin/foo-bar. When DBus wants to activate that service, it needs to adjust that Exec line based on where my snap is installed, which is only known at run time. And that's where setting DBUS_ROOT would come in for me.

So my patch to _dbus_replace_install_prefix is what really interests me and I can take or leave my other changes.

Would a patch to just that function be better received, and leave the config-file searching functions alone?

(In reply to Michael Terry from comment #4)
> Consider this snap I'm trying to make, with session dbus and installed
> session services. One such service might have an Exec line like
> Exec=/usr/bin/foo-bar. When DBus wants to activate that service, it needs
> to adjust that Exec line based on where my snap is installed, which is only
> known at run time. And that's where setting DBUS_ROOT would come in for me.

I am really not comfortable with rewriting absolute paths to mean something that isn't actually what they say - I feel as though an absolute path should lead to "you asked for it, you got it", with anything else being a violation of the least-astonishment principle. I wasn't a D-Bus maintainer at the time the Windows install-prefix-rewriting was implemented, so I've tolerated what we already had; but I'm not a fan of it extending its tentacles outside the Windows special case, and I'd like to be able to replace it with something less astonishing.

We have had efforts in the past to make D-Bus .service files relocatable in a less astonishing way, by interpreting *relative* Exec paths (which currently have no useful meaning) as relative to something (the original suggestion was dbus-daemon's $prefix, but "where I found the service file" seems better). However, I think it would also be a least-astonishment problem if a relative Exec didn't mean the same thing as it does in .desktop files, its meaning is currently undefined in .desktop files, and when I raised the equivalent question for .desktop files the conversation descended into disagreements about how the relative path should be resolved in corner cases (if you symlink a desktop file between directories, or worse, copy/symlink it to your ~/Desktop and double-click on it).

Relative paths in .desktop files also seem like something you will need for this current effort in Snap; it would be helpful to try to get some sort of consensus there. Latest attempt: <https://lists.freedesktop.org/archives/xdg/2016-June/013754.html>

I am not a huge fan of Snap's approach to relocation in general: the way Flatpak does this, with userns + bind mounts so the path really exists at least in the container's view of the filesystem, seems a lot more honest to me.

> I am really not comfortable with rewriting absolute paths to mean something that isn't actually what they say

I'm sympathetic to that position. But

A) A data file like a dbus service file simply cannot specify a full path, if its proper path is only known at run time. Which is the case for snaps, and maybe other use cases too(?).

B) In some cases, the administrator knows more about how they've set up the environment than the service author *can* know. The administrator can edit the file, sure. But an environment variable is often an easier approach for them (at least if all the administrator has done is moved its root).

For the work I'm doing, I can hack my snap to use relative paths in its bundled dbus service files (chop off their '/' prefix) and run dbus-daemon --session with a cwd of the snap root directory. That would let me use dbus's existing relative-dir support in my favor. For as long as dbus still supports that way, at least.

So I can hack it. But I was hoping for a cleaner way of doing that in a systematic way (and maybe help people doing similar things that don't have the luxury of being able to do the hack I can).

> ... with anything else being a violation of the least-astonishment principle.

I understand that what the Windows side is doing may be a bit surprising. Since that check is always on.

But with this patch, the relocation support is opt-in by setting DBUS_ROOT. In which case, the relocation would be quite expected. Maybe it would be even less likely to surprise if it was a command line argument?

> Relative paths in .desktop files also seem like something you will need

I don't *think* I'll actually need that. I'm snapping unity8, and for .desktop based application launches, it has code to prefix the correct root directory onto the Exec line (since it reads those and knows when it's running as a snap).

(In reply to Michael Terry from comment #6)
> A) A data file like a dbus service file simply cannot specify a full path,
> if its proper path is only known at run time.

I'm not disputing that - but in that situation, I really don't think it's right to specify a full path that gets rewritten internally to mean something other than what it says.

Hence the various suggestions on the .desktop file thread: paths relative to the .desktop file (or in this case the .service file), or paths relative to the loading executable's $prefix, or paths that start with some magic token. https://lists.freedesktop.org/archives/xdg/2016-June/013754.html explains those options in more detail, and explains why my preferred one of those is relative to the .desktop file.

If this is something that Canonical has a need for, please try to push the .desktop file discussion towards some sort of consensus (which might be as simple as writing detailed pseudocode for what relative paths should mean and justifying why that meaning was chosen), so that we can make relative paths in .service files do the same thing as relative paths in .desktop files. There was at least one Canonical developer (desrt) already involved in the thread I linked.

I'm afraid I don't have the mental bandwidth to reach that consensus myself - other things that I'm working on are more important to me. If reaching that consensus is more important to you than it is to me, please help.

(In reply to Michael Terry from comment #6)
> For the work I'm doing, I can hack my snap to use relative paths in its
> bundled dbus service files (chop off their '/' prefix) and run dbus-daemon
> --session with a cwd of the snap root directory. That would let me use
> dbus's existing relative-dir support in my favor. For as long as dbus still
> supports that way, at least.

To be clear, I consider this resolution of relative paths to be an accident, not a feature: it's a side-effect of how the service-spawning code is implemented. When we reach a consensus on what more useful thing should be meant by relative paths, it will change.

-- 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/159.