RFC: Implement dbus-broker-session tool

[nolange]

This is a functional replacement for dbus-run-session, as this is often a very useful tool for testing / isolation (#145)

Exit codes and behavior is very similar,
the implementation is mostly shared with dbus-broker-launch, adding some hooks to start and supervise the application.

The target is to provide a minimal implementation, which can be enabled by creating a symlink named dbus-broker-session to dbus-broker-launch. Possibly this could be extended to also allow a symlink names dbus-run-session.
More complex functionality like supporting dbus-daemon or different dbus-broker-launch versions is not planned (like in #321), but could be done with simple shell scripts.

I believe this to be the best approach, and if merged it will quickly be available in distributions.

Please give me some feedback if this is worth pursuing (more than a version that "works-for-me"). I know it needs another pass in regards of code-style atleast, so general stuff would be needed to be sorted out first.

• prefer separate functions like help / help_session or common functions with flag like parse_argv
• posix_spawn or fork/exec
• error handling is ok? in regards to sd_event + the error_fold stuff
• I used getauxval because its used already in dbus-broker. but I would prefer getrandom.?
• socket path should try RUNTIME_DIRECTORY, XDG_RUNTIME_DIR first.

[nolange]

And I am not sure if launcher_connect
should connect to the "normal" user bus or the newly created one (which I currently do by setting DBUS_SESSION_BUS_ADDRESS early).
Might be better to use sd_bus_set_fd atleast if used via dbus-broker-session.

This is needed for authentication and further launching via systemd I suppose?
dbus-run-session can be called in an environment where the user dbus / socket is not available.
For example I am preparing a debian filesystem with an per-existing user, this needs calling dconf, gsettings and gio tools through dbus-run-session for the user before he is logged in for the first time.

Ideally dbus-broker-session could run without dbus-activation feature (I expect there to be problems launching via systemd anyway).

[dvdhrm]

Thanks for the proposal! Two comments:

1. Can you explain why you share the process with the launcher rather than as a separate executable? I have to admit I think the merged approach makes this less readable than a clear separation.

2. Any reason not to simply pursue session: implement dbus-broker-session #321 instead? I mean #321 works and it is fully compatible to dbus-run-session. If you rip out the clap dependency and parse the cli manually, it should be good to go.

[nolange]

I am concerned about how this new tool is going to end up in debian, buildroot and other linux systems.
The dbus-broker-launch tool already has pretty much everything thats needed, the tool in #321 is a parallel implementation needing a separate toolchain - it would pose trouble for example since I have embedded targets at work which don't have a toolchain with rust compiler.
And on debian you typically dont install via cargo but have to package every dependency, and rust doest seem to support DSOs which means you need to rebuild every time a dependency gets a bugfix.

I also asked about the logic in launcher_connect, if there are modifications needed then its alot easier if dbus-run-session is directly coupled to dbus-broker-launch (same project or same binary) vs. detecting the required behavior across fork/exec.

1. Can you explain why you share the process with the launcher rather than as a separate executable? I have to admit I think the merged approach makes this less readable than a clear separation.

It was easier to start that way, and I there are advantages for the "busybox" approach like getting the functionality deployed quickly without any packaging changes (debian policy means every binary needs a manpage for example).
Yeah, the readability is a downside.