GitLab

I don't know where to report this, so after some detective work I assumed this is the right place. If this is not the right place to report this, please direct me where is.

Feature/bug:

Please, provide a way to configure dbus-less operation for dbus-enabled software on dbus-less systems. This is of concern mainly on dbus "client" side.

Any of the following ways would be welcome:

• environment variable
• sentinel/config file somewhere in /run (tmpfs)
• sentinel/config file somewhere in /etc (fs)

The rationale:

On some "systems", dbus is not mandatory nor wanted. Note first, that I want to avoid igniting discord, so let's try not to get into politics of such usecases, but let us concentrate on the possible solution.

Such systems might be trimmed down systems for specialty uses (like kiosks and such), chroots, ad-hoc containers and others. I also want to make a point, that all these usescases are legitimate situations.

For many reasons, even in such situations, software might be installed, that has dbus support enabled (eg. compiled-in, called from scripting lanugages (in case of dynamic languages) etc), but dbus is intentionally not working.

In most cases, unless dbus is really hard requirement, such software works fine (often with some functionality disabled - but that may even be intended by operator), even if other dbus components (like system/user level daemon) are not present (eg, installed and/or running). My problem is, this software still tries to access various system (and user) dbus daemons controlled files and resources.

Case in point:

$ some-program
...
...
(some-program:567): IBUS-WARNING **: 15:26:36.344: Unable to load /var/lib/dbus/machine-id: Failed to open file “/var/lib/dbus/machine-id”: No such file or directory

I sporadically also see accesses to other dbus machinery (sockets and whatnot).

I would like to politely ask you to provide some way for operators to hint to dbus libraries and subsystems, that dbus is not even present, so that dbus subsystems and libraries are allow to "fail" quickly and early and without access warnings or errors, and should not even bother with trying to connect somewhere.

What I mean by that: such software already works when dbus fails, but it's dbus subsystems still try to access runtime and machine specific files and resources. This proves software can work without dbus, but still causes errors and warnings to collect in processes, sometime misdirecting other users on multi-user multitenant machines and whatnot. I want to be able to drop file or perhaps define envvar somewhere, that makes dbus subsystems report something else instead of warning or error, eg. something like:

(some-program:567): IBUS-NOTICE **: 15:26:36.344: won't connect to dbus, administratively prohibited.

As for solution, envvar seemed like good first idea but then I realized, that even unprivileged users might set that, and that might be seen as security issue by some (perhaps? I don't know about lot about dbus software, but I think Network Manager has privileged parts and uses it (dbus)), or not, I don't know. So second next best idea to me appears to be presence of some "sentinel" file in root owned directories - those are not easily spoofable and only system user and system administrators have controls of those, so that might be good trade-off.

This whole thing is mostly about semantics, missing /var/lib/dbus/machine-id already indicates that dbus is not present, but does not communicate intent, eg that this configuration is intentional.

I want to be able to set this hint once and let it trickle down from system level daemons to normal user level software.

If this is successfully implemented, it would allow for this change to disseminate down the stream to many dbus consumers, fixing this issue permanently.

Of course, it is possible that there is already a way to administratively indicate described situation. In that case I have not found it, so I would like to ask you for pointers on how I can configure this on my affected machines and containers.

Thank you.