[SOLVED] disabling D-Bus

cgorac · 01-09-2018, 03:15 AM

Following is probably well-known by many, but it took me some time to figure it out, so I'll write it here for reference:

I wanted to disable D-Bus on my laptop, and all the stuff that it pulls in (ConsoleKit, PolicyKit, gconfd), however I found that "chmod ugo-x" on /etc/rc.d/rc.messagebus and /etc/rc.d/rc.consolekit has no effect, as D-Bus daemon would get started somehow anyway. So after some searching, I found it's possible to disable its launching by setting DBUS_SESSION_BUS_ADDRESS environment variable to some string that is not valid filesystem path (or something similar, as I tried with /dev/null and it worked too). Alternatively, one could of course just "chmod ugo-x /usr/bin/dbus-daemon".

I found that PulseAudio is not working afterwards, however here D-Bus seems just to be used by some PulseAudio modules, so I commented out loading Bluetooth and ConsoleKit modules in /etc/pulse/default.pa, and if works fine now.

If someone has alternate suggestions on how to achieve this, I'd like to hear.

Didier Spaier · 01-09-2018, 03:56 AM

Just edit the /usr/bin/start<graphical environment> that you use to remove or comment out the dbus launch code snippet.

e.g. in /usr/bin/startwmaker you will see this:

Code:

 if [ -z "$DBUS_SESSION_BUS_ADDRESS" ]; then
   eval `dbus-launch --sh-syntax --exit-with-session`
fi

Of course if you don't use any graphical environment this is pointless

But if you use Lumina, if I understand well you won't need this plumbing anyway as they don't use it.

cgorac · 01-09-2018, 04:16 AM

Thanks for the hint.

I'm still somewhat confused how it get started in my case. Namely, I'm using Openbox. My machine boots into runlevel 3, and then I have .bash_login set up so that if I login at tty1, it would run xinit, that in turn would find in my ~/.xinitrc that it should exec openbox-session. The Openbox scripts don't mention dbus-launch, and according to pstree output, it doesn't seem to be active after X started. However, as soon as I start any GTK program (I'm using Emacs, Firefox and Xpdf - I think all of these are GTK3 by now), dbus-daemon would appear in the pstree output, accompanied by all the other fellas: ConsoleKit and PolicyKit daemons, gconfd daemon, and even some accessibility daemons in case Emacs launched.

Didier Spaier · 01-09-2018, 04:50 AM

I didn't dig but assume that these apps do use some mechanism to do so, like dbus-glib.

Out of curiosity I did this to find which packages depend on dbus in Slackware64-14.2:

Code:

wget http://slackware.uk/salix/x86_64/slackware-14.2/PACKAGES.TXT
grep -B4 dbus, PACKAGES.TXT|grep NAME|sed "s/.* //;s/-[^-]*-[^-]*-[^-]*$//" > packages_depending_on_dbus.txt

The output is attached. Maybe you can compile some of them without dbus if there is a configure option to do that. Good luck.

PS grepping "dbus," may be makes miss a few, but you get the idea.

cgorac · 01-09-2018, 05:25 AM

Quote:

Originally Posted by Didier Spaier

I didn't dig but assume that these apps do use some mechanism to do so, like dbus-glib.

Yeah, probably. It seems to me that GTK is more "problematic" toolkit than Qt in the sense that the separation between the toolkit and the desktop environment that is based on the toolkit is more blurred, so applications written using the toolkit often inadvertently end up depending on corresponding desktop environment technologies.

In any case, it's early to tell but it seems that apps that I use work fine (admittedly, it's also rather small sample, as I actually spend most of my day in xterm) with the setup described above, so there is no need to recompile anything. Still, it would be nice if the whole thing was designed to be fully optional.

ernobe · 03-07-2018, 02:41 PM

On Debian SID, I have dbus disabled by not installing dbus-user-session (it is recommended by the pulseaudio package), or dbus-x11, which automatically brings up dbus on X startup.

EDIT: Oops just realized this is a Slackware forum. Anyway, dbus-x11 is Debians' package containing dbus-launch, which is what programs use to automatically launch dbus. Just removing it ought to solve your unwanted dbus problems. If you still have problems with it on the (non-X) console, consider switching your init system (on Debian switch from using systemd-sysv to sysvinit-core).

slalik · 03-07-2018, 03:12 PM

I do the following:

Code:

# chmod -x /usr/bin/dbus-launch
# chattr +i /usr/bin/dbus-launch

and, of course,

Code:

# chmod -x /etc/rc.d/rc.messagebus

Also, I put the following to /etc/rc.d/rc.local:

Code:

# Ensure the existence of /var/lib/dbus/machine-id
if [ -x /usr/bin/dbus-uuidgen -a ! -x /etc/rc.d/rc.messagebus ] ; then
  echo "Ensure that /var/lib/dbus/machine-id exists: /usr/bin/dbus-uuidgen --ensure"
  /usr/bin/dbus-uuidgen --ensure
fi

igadoter · 03-08-2018, 09:48 AM

Quote:

Originally Posted by slalik

I do the following:

Code:

# chmod -x /usr/bin/dbus-launch
# chattr +i /usr/bin/dbus-launch

Don't understand what the purpose to set 'i' attribute for executable. I mean what kind of process can change this file again to be executable? If there is such process I consider this as serious security gap. I mean say something is trying to run dbus-lunch - but can't - it should possible send signal - go sleep - or terminate with information in syslog - or its own log file - that something is missing. Such kind of things.

slalik · 03-08-2018, 11:22 AM

Quote:

Originally Posted by igadoter

Don't understand what the purpose to set 'i' attribute for executable. I mean what kind of process can change this file again to be executable?

Upgrade of the dbus!