Why do we need d-bus?

kpedersen

Son of Beastie

Reaction score: 2,096
Messages: 2,954

Jose I *think* transmission bittorrent client uses it for the console interface (transmission-remote-cli).

I remember many years back switching from transmission to rtorrent because something stopped working and I am going to make a wild guess that it was probably dbus.
 

wolffnx

Aspiring Daemon

Reaction score: 231
Messages: 677

Is there some flag I can set to get programs to build with gtk2 instead in my make.conf? fuck gtk3, honestly.



Another service I want gone from mysystem anyways.

[Mod: Watch your language]
I wish..some applications remove the gtk2 support and change to gtk3, me too, I hate gtk3
but I dont want to make offtopic
 

jamie

New Member

Reaction score: 5
Messages: 15

Jose I *think* transmission bittorrent client uses it for the console interface (transmission-remote-cli).

I remember many years back switching from transmission to rtorrent because something stopped working and I am going to make a wild guess that it was probably dbus.
Nahhh, not transmission-remote. I think the qt/gtk gui ports need it (I don't use them) but transmission-remote uses its own rpc
 

Trihexagonal

Son of Beastie

Reaction score: 2,436
Messages: 2,955

Seriously, I don't understand why people keep introducing bloat into programs, usually upstream. Like they have a cluttered state of mind.

Respectfully, I have never understood why people make such a big deal of it or hal.

I build all my 3rd party programs from ports using ports-mgmt/portmaster starting with things not needing X to run. Then x11/xorg, x11-wm/fluxbox on up.

ports-mgmt/portmaster is the first thing I build using make install clean then from that point on I let it build everything. If it deems it necessary to pull a dependency in I go with what it thinks need pulled in during the build. I enable both in /etc/rc.conf early on so when they are installed they're ready to go when needed.

I have a minimal number of 3rd party programs installed and the same ones on every machine, give or take a game or something, and ended up with Packages: 561 on this box and close to that on every machine I build.

I had these processes showing ATM I copied and pasted them to text editor:

Code:
43402 root          1  52    0    14M  1104K select   2   0:00   0.00% dbus-launch
59551 jitte           1 22    0    14M   1104K select  1   0:00    0.00% dbus-launch
60081 jitte           1 20    0     12M  1632K select  0    0:01  0.00% dbus-daemon
98510 messagebus    1  20    0     13M  1648K select     2    0:00     0.00% dbus-daemon

top shows this load on a AMD Phenom II x 3 N830 Triple Core @ 2.1GHz with 4GB RAM:

54 processes: 2 running, 52 sleeping
CPU: 3.5% user, 0.0% nice, 1.0% system, 0.3% interrupt, 95.2% idle
Mem: 805M Active, 1929M Inact, 95M Laundry, 733M Wired, 370M Buf, 127M Free
Swap: 3852M Total, 109M Used, 3743M Free, 2% Inuse

That's running my media player for tunes, file manager, terminal emulator, text editor www/firefox-esr with a few tabs open, etc. and what is normal desktop use for me unless working with images. I don't see that as or experience a load on my boxen and it's happy happy joy joy for me.
 

PMc

Daemon

Reaction score: 680
Messages: 1,367

Respectfully, I have never understood why people make such a big deal of it or hal.
Security?

Imagine, you were the boss of some shop with a couple of employees. Would you like it to have an employee hanging around where you don't know why he was engaged, what would be his specific tasks and what he were actually doing?
That's about the same with a machine you are running, and a couple of daemons engaged to work on that machine.
 

Trihexagonal

Son of Beastie

Reaction score: 2,436
Messages: 2,955

Security?

Imagine, you were the boss of some shop with a couple of employees. Would you like it to have an employee hanging around where you don't know why he was engaged, what would be his specific tasks and what he were actually doing?
That's about the same with a machine you are running, and a couple of daemons engaged to work on that machine.

I would say not nearly the same with my machines. I am very security oriented beyond the browser extensions I use. Here are some things I do that aren't all included in my Tutorial but free to be known, used with it and what I consider good practice:

/etc/rc.conf

syslogd_flags="-c -ss"
sendmail_enable="NO"
tcp_drop_synfin="YES"
sshd_enable="NO"
telnet_enable="NO"
cupsd_enable="NO"
samba_enable="NO"
inetd_enable="NO"
rlogin_enable="NO"
portmap_enable="NO"
winbindd_enable="NO"
lpd_enable="NO"
nfs_server_enable="NO"
nfs_client_enable="NO"
webcamd_enable="NO"

My ruleset is set to block and has been posted before. Here it is again:

etc/pf.conf

### Macro name for external interface
ext_if = "bge0"
netbios_tcp = "{ 22, 23, 25, 80, 110, 111, 123, 512, 513, 514, 515, 6000, 6010 }"
netbios_udp = "{ 123, 512, 513, 514, 515, 5353, 6000, 6010 }"

### Reassemble fragmented packets
scrub in on $ext_if all fragment reassemble

### Default deny everything
block log all

### Pass loopback
set skip on lo0

### Block spooks
antispoof for lo0
antispoof for $ext_if inet
block in from no-route to any
block in from urpf-failed to any
block in quick on $ext_if from any to 255.255.255.255
block in log quick on $ext_if from { 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 255.255.255.255/32 } to any

### Block all IPv6
block in quick inet6 all
block out quick inet6 all

### Block to and from port 0
block quick proto { tcp, udp } from any port = 0 to any
block quick proto { tcp, udp } from any to any port = 0

### Block specific ports
block in quick log on $ext_if proto tcp from any to any port $netbios_tcp
block in quick log on $ext_if proto udp from any to any port $netbios_udp

### Keep and modulate state of outbound tcp, udp and icmp traffic
pass out on $ext_if proto { tcp, udp, icmp } from any to any modulate state

From the terminal:
jitte@jigoku:/ $ who
jitte ttyv0 Jan 28 23:24
jitte pts/0 Jan 28 23:25 ( : 0 )
jitte@jigoku:/ $

(I fixed that last line from a smiley emoji it made here.)

I run security/rkhunter to check for rootkits and file changes but stopped bothering with things like security/aide long ago. security/bcrypt and USB sticks what I place my trust in for password security. There may be more but haven't had enough coffee to think of.

There are no Instant Messenger apps of any kind on my machine. I do everything from my usr account and su to become root, which some see as bad practice but all I have ever used and am comfortable working as. When I work as root it is only work done needed as root and then I log out back into my usr account.

No browsers are open during that time and I may pull the Ethernet wire from the laptop if I enter the password and work. No wi-fi or bluetooth allowed in my house unless I invoke Kali to see with eyes of the Goddess.

If there are Daemons in my boxen talking to somebody they're only chatting with the Daemons in my mind through my fingertips as I type. I know some apps phone home but I brush aside the Dragons warned of that dwell in the depths of about:config. I'm boring anyway and not very interesting, for the most part.

If you have concerns that this and selectively allowing JS to run online don't cover and I'm missing something please do tell. I'd rather hear it from you than surprise by exploit from my Finnish Fans afar that tell bedtime stories of the Demon to frighten children.

Boo!
 

BSD-Kitsune

Active Member

Reaction score: 77
Messages: 185

To answer the OP's original question (also been a long time since I've been around haha)

dbus is not a BSD thing, nor is it strictly necessary on our systems. It's an IPC, socket-activation and object model daemon designed for GNU/Linux, first and foremost. Outside of that context, it came to the BSDs with HALd (which we've abandoned, but illumos hasn't yet, unfortunately) and it crept into consolekit and other things.

On FreeBSD, you can avoid GTK3 from requiring dbus, similar to KISS Linux and other minimalist distros. This is the flags I use:


Code:
DEFAULT_VERSIONS= python=3.7 python3=3.7 python2=2.7 llvm=11

OPTIONS_UNSET+= CUPS DBUS DEBUG DOCS DTRACE EXAMPLES \
JACK IPV6 NLS OPENAL OPENMP OPENCV
OPTIONS_SET+=OPTIMIZED_CFLAGS CPUFLAGS
WITHOUT_CUPS=YES
WITHOUT_DBUS=YES
x11-toolkits_gtk30_UNSET += ATK_BRIDGE COLORD

Although, I may end up using GCC again as a main compiler, for reasons I won't get into. Hence ignore the OpenMP and other ones there. The one is the x11-toolkits_gtk30_UNSET. I'm sticking on 12.x as well, so keep that in mind.

Really, if I had it my way, I'd require all ports that can have dbus optional upstream have it OFF by default, and those that didn't have it optional I'd remove entirely. I'm well aware of the implications of that decision, and aware it would upset dozens of people. It's a linuxism, though, and not a good one.
 

msplsh

Aspiring Daemon

Reaction score: 200
Messages: 586

Having written programs to send things over unix sockets FreeBSD and also over more structured RPC/IPC methods on macOS/iOS, it's probably a nice thing to have a higher level mechanism to do these sorts of things for programmers on FreeBSD, and I'm glad they have all standardized on it.

That being said I do try and turn it off via build options for things that seemingly don't need it since I'm rarely using FreeBSD with X. This just seems like a packaging complaint.
 

rigoletto@

Daemon
Developer

Reaction score: 1,252
Messages: 2,293

As some folks said D-Bus is a IPC (Inter-Process Communication) but a kind of hacky one. IPCs are fundamental when using microkernels (you can get a lot of technical information about the MacOS Mach IPC); given the natural simplicity and isolation of these kernels a lot communication between "applications" happen through the IPC according to a given security police instead of (freely) "directly".

However, it may have use in other applications too. x11-wm/bspwm, x11-wm/i3, x11-wm/leftwm are some WMs with simple built-in IPC (or sort of IPC) to pass commands directly to the WM (quite handy in some circumstances).

In regards to D-Bus, this is the typical Linux (more like general weekend hobbyist open-source) development, where it isn't secure (or at least doens't improve security at all) nor it is actually usefull (hard to use it from the user point of view, or more like useless). In other words, more of a source of problems or a solution that bring more problems than the problem it is trying to solve (improve security).

[EDIT]

Just to make it clear serious IPCs are pretty hard to design/implement properly. Surely not a weekend hobbyist job unless he/she is an experienced IPC developer.
 

Jose

Daemon

Reaction score: 1,006
Messages: 1,209

Sometimes worrying about it isn't worth the time.
And sometimes it is.
 

msplsh

Aspiring Daemon

Reaction score: 200
Messages: 586

This is not a dbus security flaw, which is why it's labeled polkit.
 

Jose

Daemon

Reaction score: 1,006
Messages: 1,209

This is not a dbus security flaw, which is why it's labeled polkit.
Reading TFA helps.

The vulnerability​


Why does killing the dbus-send command cause an authentication bypass? The vulnerability is in step four of the sequence of events listed above. What happens if polkit asks dbus-daemon for the UID of connection :1.96, but connection :1.96 no longer exists? dbus-daemon handles that situation correctly and returns an error. But it turns out that polkit does not handle that error correctly. In fact, polkit mishandles the error in a particularly unfortunate way: rather than rejecting the request, it treats the request as though it came from a process with UID 0. In other words, it immediately authorizes the request because it thinks the request has come from a root process.
 

Jose

Daemon

Reaction score: 1,006
Messages: 1,209

I'm not entirely certain what I'm supposed to glean from that article, but here are some gems from a quick scan.
While D-Bus does offer 1-to-1 and 1-to-many IPC, it’s more of a byproduct of its original purpose than a mean of efficient process to process data transfer — it isn’t meant to be fast.
The accidental IPC! I really wanna use it now.
Its design is heavily influenced by Service Oriented Architectures (SOA), Enterprise Service Buses (ESB), and microkernel architectures.
A bus permits abstracting communication between software, replacing all direct contact, and only allowing them to happen on the bus instead.
Additionally, the SOA allows software to expose objects that have methods that can be called remotely, and also allows other software to subscribe/publish events happening in remote objects residing in other software.
Moreover, D-Bus provides an easy plug-and-play, a loose coupling, where any software could detach itself from the bus and allow another process to be plugged, containing objects that implement the same features the previous process implemented.
...
Interfaces can be described as standard, and for documentation, in D-Bus XML configuration files so that other programmers can use the reference to implement them properly. These files can also be used to auto-generate classes from the XML, making it quicker to implement and less error-prone.
How very enterprise! I wonder if it has AbstractFactoryFactories.
 

CanvisMe

New Member

Reaction score: 1
Messages: 14

So how can I entirely disable dbus. While I'm using ports to build qt related pkgs, there's USE_QT = dbus option in some qt pkg Makefile.
 

astyle

Daemon

Reaction score: 488
Messages: 1,130

Why do people choose 112th anniversary of Chicago's massacre (google that yourselves, I'm not posting links for this one) to post to the forums?

Anyway, DBUS is an implementation of IPC (as pointed out earlier in this thread. So, CanvisMe , I would discourage disabling dbus. It takes a lot of expertise to know about alternative solutions that actually work, and can be used as a drop-in replacement. IPC is vitally important to proper functioning of desktops in FreeBSD. If you don't like DBUS, you'd need to be comfortable with getting down and dirty with the source code of the desktops themselves.
 

CanvisMe

New Member

Reaction score: 1
Messages: 14

Why do people choose 112th anniversary of Chicago's massacre (google that yourselves, I'm not posting links for this one) to post to the forums?

Anyway, DBUS is an implementation of IPC (as pointed out earlier in this thread. So, CanvisMe , I would discourage disabling dbus. It takes a lot of expertise to know about alternative solutions that actually work, and can be used as a drop-in replacement. IPC is vitally important to proper functioning of desktops in FreeBSD. If you don't like DBUS, you'd need to be comfortable with getting down and dirty with the source code of the desktops themselves.
I'm sorry for that, and I'll take your advice, thanks
 

Jose

Daemon

Reaction score: 1,006
Messages: 1,209

So how can I entirely disable dbus. While I'm using ports to build qt related pkgs, there's USE_QT = dbus option in some qt pkg Makefile.
Look upthread:
 
Top