1DBUS-DAEMON(1)                   User Commands                  DBUS-DAEMON(1)
2
3
4

NAME

6       dbus-daemon - Message bus daemon
7

SYNOPSIS

9       dbus-daemon
10
11       dbus-daemon [--version] [--session] [--system] [--config-file=FILE]
12                   [--print-address [=DESCRIPTOR]] [--print-pid [=DESCRIPTOR]]
13                   [--fork] [--nosyslog] [--syslog] [--syslog-only]
14
15

DESCRIPTION

17       dbus-daemon is the D-Bus message bus daemon. See
18       http://www.freedesktop.org/software/dbus/ for more information about
19       the big picture. D-Bus is first a library that provides one-to-one
20       communication between any two applications; dbus-daemon is an
21       application that uses this library to implement a message bus daemon.
22       Multiple programs connect to the message bus daemon and can exchange
23       messages with one another.
24
25       There are two standard message bus instances: the systemwide message
26       bus (installed on many systems as the "messagebus" init service) and
27       the per-user-login-session message bus (started each time a user logs
28       in).  dbus-daemon is used for both of these instances, but with a
29       different configuration file.
30
31       The --session option is equivalent to
32       "--config-file=/usr/share/dbus-1/session.conf" and the --system option
33       is equivalent to "--config-file=/usr/share/dbus-1/system.conf". By
34       creating additional configuration files and using the --config-file
35       option, additional special-purpose message bus daemons could be
36       created.
37
38       The systemwide daemon is normally launched by an init script,
39       standardly called simply "messagebus".
40
41       The systemwide daemon is largely used for broadcasting system events,
42       such as changes to the printer queue, or adding/removing devices.
43
44       The per-session daemon is used for various interprocess communication
45       among desktop applications (however, it is not tied to X or the GUI in
46       any way).
47
48       SIGHUP will cause the D-Bus daemon to PARTIALLY reload its
49       configuration file and to flush its user/group information caches. Some
50       configuration changes would require kicking all apps off the bus; so
51       they will only take effect if you restart the daemon. Policy changes
52       should take effect with SIGHUP.
53

OPTIONS

55       The following options are supported:
56
57       --config-file=FILE
58           Use the given configuration file.
59
60       --fork
61           Force the message bus to fork and become a daemon, even if the
62           configuration file does not specify that it should. In most
63           contexts the configuration file already gets this right, though.
64           This option is not supported on Windows.
65
66       --nofork
67           Force the message bus not to fork and become a daemon, even if the
68           configuration file specifies that it should. On Windows, the
69           dbus-daemon never forks, so this option is allowed but does
70           nothing.
71
72       --print-address[=DESCRIPTOR]
73           Print the address of the message bus to standard output, or to the
74           given file descriptor. This is used by programs that launch the
75           message bus.
76
77       --print-pid[=DESCRIPTOR]
78           Print the process ID of the message bus to standard output, or to
79           the given file descriptor. This is used by programs that launch the
80           message bus.
81
82       --session
83           Use the standard configuration file for the per-login-session
84           message bus.
85
86       --system
87           Use the standard configuration file for the systemwide message bus.
88
89       --version
90           Print the version of the daemon.
91
92       --introspect
93           Print the introspection information for all D-Bus internal
94           interfaces.
95
96       --address[=ADDRESS]
97           Set the address to listen on. This option overrides the address
98           configured in the configuration file via the <listen> directive.
99           See the documentation of that directive for more details.
100
101       --systemd-activation
102           Enable systemd-style service activation. Only useful in conjunction
103           with the systemd system and session manager on Linux.
104
105       --nopidfile
106           Don't write a PID file even if one is configured in the
107           configuration files.
108
109       --syslog
110           Force the message bus to use the system log for messages, in
111           addition to writing to standard error, even if the configuration
112           file does not specify that it should. On Unix, this uses the
113           syslog; on Windows, this uses OutputDebugString().
114
115       --syslog-only
116           Force the message bus to use the system log for messages, and not
117           duplicate them to standard error. On Unix, this uses the syslog; on
118           Windows, this uses OutputDebugString().
119
120       --nosyslog
121           Force the message bus to use only standard error for messages, even
122           if the configuration file specifies that it should use the system
123           log.
124

CONFIGURATION FILE

126       A message bus daemon has a configuration file that specializes it for a
127       particular application. For example, one configuration file might set
128       up the message bus to be a systemwide message bus, while another might
129       set it up to be a per-user-login-session bus.
130
131       The configuration file also establishes resource limits, security
132       parameters, and so forth.
133
134       The configuration file is not part of any interoperability
135       specification and its backward compatibility is not guaranteed; this
136       document is documentation, not specification.
137
138       The standard systemwide and per-session message bus setups are
139       configured in the files "/usr/share/dbus-1/system.conf" and
140       "/usr/share/dbus-1/session.conf". These files normally <include> a
141       system-local.conf or session-local.conf in /etc/dbus-1; you can put
142       local overrides in those files to avoid modifying the primary
143       configuration files.
144
145       The configuration file is an XML document. It must have the following
146       doctype declaration:
147
148
149              <!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-Bus Bus Configuration 1.0//EN"
150               "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">
151
152
153       The following elements may be present in the configuration file.
154
155       ·   <busconfig>
156
157       Root element.
158
159       ·   <type>
160
161       The well-known type of the message bus. Currently known values are
162       "system" and "session"; if other values are set, they should be either
163       added to the D-Bus specification, or namespaced. The last <type>
164       element "wins" (previous values are ignored). This element only
165       controls which message bus specific environment variables are set in
166       activated clients. Most of the policy that distinguishes a session bus
167       from the system bus is controlled from the other elements in the
168       configuration file.
169
170       If the well-known type of the message bus is "session", then the
171       DBUS_STARTER_BUS_TYPE environment variable will be set to "session" and
172       the DBUS_SESSION_BUS_ADDRESS environment variable will be set to the
173       address of the session bus. Likewise, if the type of the message bus is
174       "system", then the DBUS_STARTER_BUS_TYPE environment variable will be
175       set to "system" and the DBUS_SESSION_BUS_ADDRESS environment variable
176       will be set to the address of the system bus (which is normally well
177       known anyway).
178
179       Example: <type>session</type>
180
181       ·   <include>
182
183       Include a file <include>filename.conf</include> at this point. If the
184       filename is relative, it is located relative to the configuration file
185       doing the including.
186
187       <include> has an optional attribute "ignore_missing=(yes|no)" which
188       defaults to "no" if not provided. This attribute controls whether it's
189       a fatal error for the included file to be absent.
190
191       ·   <includedir>
192
193       Include all files in <includedir>foo.d</includedir> at this point.
194       Files in the directory are included in undefined order. Only files
195       ending in ".conf" are included.
196
197       This is intended to allow extension of the system bus by particular
198       packages. For example, if CUPS wants to be able to send out
199       notification of printer queue changes, it could install a file to
200       /usr/share/dbus-1/system.d or /etc/dbus-1/system.d that allowed all
201       apps to receive this message and allowed the printer daemon user to
202       send it.
203
204       ·   <user>
205
206       The user account the daemon should run as, as either a username or a
207       UID. If the daemon cannot change to this UID on startup, it will exit.
208       If this element is not present, the daemon will not change or care
209       about its UID.
210
211       The last <user> entry in the file "wins", the others are ignored.
212
213       The user is changed after the bus has completed initialization. So
214       sockets etc. will be created before changing user, but no data will be
215       read from clients before changing user. This means that sockets and PID
216       files can be created in a location that requires root privileges for
217       writing.
218
219       ·   <fork>
220
221       If present, the bus daemon becomes a real daemon (forks into the
222       background, etc.). This is generally used rather than the --fork
223       command line option.
224
225       ·   <keep_umask>
226
227       If present, the bus daemon keeps its original umask when forking. This
228       may be useful to avoid affecting the behavior of child processes.
229
230       ·   <syslog>
231
232       If present, the bus daemon will log to syslog. The --syslog,
233       --syslog-only and --nosyslog command-line options take precedence over
234       this setting.
235
236       ·   <pidfile>
237
238       If present, the bus daemon will write its pid to the specified file.
239       The --nopidfile command-line option takes precedence over this setting.
240
241       ·   <allow_anonymous>
242
243       If present, connections that authenticated using the ANONYMOUS
244       mechanism will be authorized to connect. This option has no practical
245       effect unless the ANONYMOUS mechanism has also been enabled using the
246       <auth> element, described below.
247
248       Using this directive in the configuration of the well-known system bus
249       or the well-known session bus will make that bus insecure and should
250       never be done. Similarly, on custom bus types, using this directive
251       will usually make the custom bus insecure, unless its configuration has
252       been specifically designed to prevent anonymous users from causing
253       damage or escalating privileges.
254
255       ·   <listen>
256
257       Add an address that the bus should listen on. The address is in the
258       standard D-Bus format that contains a transport name plus possible
259       parameters/options.
260
261       On platforms other than Windows, unix-based transports (unix, systemd,
262       launchd) are the default for both the well-known system bus and the
263       well-known session bus, and are strongly recommended.
264
265       On Windows, unix-based transports are not available, so TCP-based
266       transports must be used. Similar to remote X11, the tcp and nonce-tcp
267       transports have no integrity or confidentiality protection, so they
268       should normally only be used across the local loopback interface, for
269       example using an address like tcp:host=127.0.0.1 or
270       nonce-tcp:host=localhost. In particular, configuring the well-known
271       system bus or the well-known session bus to listen on a non-loopback
272       TCP address is insecure.
273
274       Developers are sometimes tempted to use remote TCP as a debugging tool.
275       However, if this functionality is left enabled in finished products,
276       the result will be dangerously insecure. Instead of using remote TCP,
277       developers should relay connections via Secure Shell or a similar
278       protocol[1].
279
280       Remote TCP connections were historically sometimes used to share a
281       single session bus between login sessions of the same user on different
282       machines within a trusted local area network, in conjunction with
283       unencrypted remote X11, a NFS-shared home directory and NIS (YP)
284       authentication. This is insecure against an attacker on the same LAN
285       and should be considered strongly deprecated; more specifically, it is
286       insecure in the same ways and for the same reasons as unencrypted
287       remote X11 and NFSv2/NFSv3. The D-Bus maintainers recommend using a
288       separate session bus per (user, machine) pair, only accessible from
289       within that machine.
290
291       Example: <listen>unix:path=/tmp/foo</listen>
292
293       Example: <listen>tcp:host=localhost,port=1234</listen>
294
295       If there are multiple <listen> elements, then the bus listens on
296       multiple addresses. The bus will pass its address to started services
297       or other interested parties with the last address given in <listen>
298       first. That is, apps will try to connect to the last <listen> address
299       first.
300
301       tcp sockets can accept IPv4 addresses, IPv6 addresses or hostnames. If
302       a hostname resolves to multiple addresses, the server will bind to all
303       of them. The family=ipv4 or family=ipv6 options can be used to force it
304       to bind to a subset of addresses
305
306       Example: <listen>tcp:host=localhost,port=0,family=ipv4</listen>
307
308       A special case is using a port number of zero (or omitting the port),
309       which means to choose an available port selected by the operating
310       system. The port number chosen can be obtained with the --print-address
311       command line parameter and will be present in other cases where the
312       server reports its own address, such as when DBUS_SESSION_BUS_ADDRESS
313       is set.
314
315       Example: <listen>tcp:host=localhost,port=0</listen>
316
317       tcp/nonce-tcp addresses also allow a bind=hostname option, used in a
318       listenable address to configure the interface on which the server will
319       listen: either the hostname is the IP address of one of the local
320       machine's interfaces (most commonly 127.0.0.1), a DNS name that
321       resolves to one of those IP addresses, '0.0.0.0' to listen on all IPv4
322       interfaces simultaneously, or '::' to listen on all IPv4 and IPv6
323       interfaces simultaneously (if supported by the OS). If not specified,
324       the default is the same value as "host".
325
326       Example: <listen>tcp:host=localhost,bind=0.0.0.0,port=0</listen>
327
328       ·   <auth>
329
330       Lists permitted authorization mechanisms. If this element doesn't
331       exist, then all known mechanisms are allowed. If there are multiple
332       <auth> elements, all the listed mechanisms are allowed. The order in
333       which mechanisms are listed is not meaningful.
334
335       On non-Windows operating systems, allowing only the EXTERNAL
336       authentication mechanism is strongly recommended. This is the default
337       for the well-known system bus and for the well-known session bus.
338
339       Example: <auth>EXTERNAL</auth>
340
341       Example: <auth>DBUS_COOKIE_SHA1</auth>
342
343       ·   <servicedir>
344
345       Adds a directory to search for .service files, which tell the
346       dbus-daemon how to start a program to provide a particular well-known
347       bus name. See the D-Bus Specification for more details about the
348       contents of .service files.
349
350       If a particular service is found in more than one <servicedir>, the
351       first directory listed in the configuration file takes precedence. If
352       two service files providing the same well-known bus name are found in
353       the same directory, it is arbitrary which one will be chosen (this can
354       only happen if at least one of the service files does not have the
355       recommended name, which is its well-known bus name followed by
356       ".service").
357
358       ·   <standard_session_servicedirs/>
359
360       <standard_session_servicedirs/> requests a standard set of session
361       service directories. Its effect is similar to specifying a series of
362       <servicedir/> elements for each of the data directories, in the order
363       given here. It is not exactly equivalent, because there is currently no
364       way to disable directory monitoring or enforce strict service file
365       naming for a <servicedir/>.
366
367       As with <servicedir/> elements, if a particular service is found in
368       more than one service directory, the first directory takes precedence.
369       If two service files providing the same well-known bus name are found
370       in the same directory, it is arbitrary which one will be chosen (this
371       can only happen if at least one of the service files does not have the
372       recommended name, which is its well-known bus name followed by
373       ".service").
374
375       On Unix, the standard session service directories are:
376
377       ·   $XDG_RUNTIME_DIR/dbus-1/services, if XDG_RUNTIME_DIR is set (see
378           the XDG Base Directory Specification for details of
379           XDG_RUNTIME_DIR): this location is suitable for transient services
380           created at runtime by systemd generators (see
381           systemd.generator(7)), session managers or other session
382           infrastructure. It is an extension provided by the reference
383           implementation of dbus-daemon, and is not standardized in the D-Bus
384           Specification.
385
386           Unlike the other standard session service directories, this
387           directory enforces strict naming for the service files: the
388           filename must be exactly the well-known bus name of the service,
389           followed by ".service".
390
391           Also unlike the other standard session service directories, this
392           directory is never monitored with inotify(7) or similar APIs.
393           Programs that create service files in this directory while a
394           dbus-daemon is running are expected to call the dbus-daemon's
395           ReloadConfig() method after they have made changes.
396
397       ·   $XDG_DATA_HOME/dbus-1/services, where XDG_DATA_HOME defaults to
398           ~/.local/share (see the XDG Base Directory Specification): this
399           location is specified by the D-Bus Specification, and is suitable
400           for per-user, locally-installed software.
401
402       ·   directory/dbus-1/services for each directory in XDG_DATA_DIRS,
403           where XDG_DATA_DIRS defaults to /usr/local/share:/usr/share (see
404           the XDG Base Directory Specification): these locations are
405           specified by the D-Bus Specification. The defaults are suitable for
406           software installed locally by a system administrator
407           (/usr/local/share) or for software installed from operating system
408           packages (/usr/share). Per-user or system-wide configuration that
409           sets the XDG_DATA_DIRS environment variable can extend this search
410           path to cover installations in other locations, for example
411           ~/.local/share/flatpak/exports/share/ and
412           /var/lib/flatpak/exports/share/ when flatpak(1) is used.
413
414       ·   ${datadir}/dbus-1/services for the ${datadir} that was specified
415           when dbus was compiled, typically /usr/share: this location is an
416           extension provided by the reference dbus-daemon implementation, and
417           is suitable for software stacks installed alongside dbus-daemon.
418
419       The "XDG Base Directory Specification" can be found at
420       http://freedesktop.org/wiki/Standards/basedir-spec if it hasn't moved,
421       otherwise try your favorite search engine.
422
423       On Windows, the standard session service directories are:
424
425       ·   %CommonProgramFiles%/dbus-1/services if %CommonProgramFiles% is
426           set: this location is suitable for system-wide installed software
427           packages
428
429       ·   A share/dbus-1/services directory found in the same directory
430           hierarchy (prefix) as the dbus-daemon: this location is suitable
431           for software stacks installed alongside dbus-daemon
432
433       The <standard_session_servicedirs/> option is only relevant to the
434       per-user-session bus daemon defined in /etc/dbus-1/session.conf.
435       Putting it in any other configuration file would probably be nonsense.
436
437       ·   <standard_system_servicedirs/>
438
439       <standard_system_servicedirs/> specifies the standard system-wide
440       activation directories that should be searched for service files. As
441       with session services, the first directory listed has highest
442       precedence.
443
444       On Unix, the standard session service directories are:
445
446       ·   /usr/local/share/dbus-1/system-services: this location is specified
447           by the D-Bus Specification, and is suitable for software installed
448           locally by the system administrator
449
450       ·   /usr/share/dbus-1/system-services: this location is specified by
451           the D-Bus Specification, and is suitable for software installed by
452           operating system packages
453
454       ·   ${datadir}/dbus-1/system-services for the ${datadir} that was
455           specified when dbus was compiled, typically /usr/share: this
456           location is an extension provided by the reference dbus-daemon
457           implementation, and is suitable for software stacks installed
458           alongside dbus-daemon
459
460       ·   /lib/dbus-1/system-services: this location is specified by the
461           D-Bus Specification, and was intended for software installed by
462           operating system packages and used during early boot (but it should
463           be considered deprecated, because the reference dbus-daemon is not
464           designed to be available during early boot)
465
466       On Windows, there is no standard system bus, so there are no standard
467       system bus directories either.
468
469       The <standard_system_servicedirs/> option is only relevant to the
470       per-system bus daemon defined in /usr/share/dbus-1/system.conf. Putting
471       it in any other configuration file would probably be nonsense.
472
473       ·   <servicehelper/>
474
475       <servicehelper/> specifies the setuid helper that is used to launch
476       system daemons with an alternate user. Typically this should be the
477       dbus-daemon-launch-helper executable in located in libexec.
478
479       The <servicehelper/> option is only relevant to the per-system bus
480       daemon defined in /usr/share/dbus-1/system.conf. Putting it in any
481       other configuration file would probably be nonsense.
482
483       ·   <limit>
484
485       <limit> establishes a resource limit. For example:
486
487             <limit name="max_message_size">64</limit>
488             <limit name="max_completed_connections">512</limit>
489
490       The name attribute is mandatory. Available limit names are:
491
492                 "max_incoming_bytes"         : total size in bytes of messages
493                                                incoming from a single connection
494                 "max_incoming_unix_fds"      : total number of unix fds of messages
495                                                incoming from a single connection
496                 "max_outgoing_bytes"         : total size in bytes of messages
497                                                queued up for a single connection
498                 "max_outgoing_unix_fds"      : total number of unix fds of messages
499                                                queued up for a single connection
500                 "max_message_size"           : max size of a single message in
501                                                bytes
502                 "max_message_unix_fds"       : max unix fds of a single message
503                 "service_start_timeout"      : milliseconds (thousandths) until
504                                                a started service has to connect
505                 "auth_timeout"               : milliseconds (thousandths) a
506                                                connection is given to
507                                                authenticate
508                 "pending_fd_timeout"         : milliseconds (thousandths) a
509                                                fd is given to be transmitted to
510                                                dbus-daemon before disconnecting the
511                                                connection
512                 "max_completed_connections"  : max number of authenticated connections
513                 "max_incomplete_connections" : max number of unauthenticated
514                                                connections
515                 "max_connections_per_user"   : max number of completed connections from
516                                                the same user
517                 "max_pending_service_starts" : max number of service launches in
518                                                progress at the same time
519                 "max_names_per_connection"   : max number of names a single
520                                                connection can own
521                 "max_match_rules_per_connection": max number of match rules for a single
522                                                   connection
523                 "max_replies_per_connection" : max number of pending method
524                                                replies per connection
525                                                (number of calls-in-progress)
526                 "reply_timeout"              : milliseconds (thousandths)
527                                                until a method call times out
528
529       The max incoming/outgoing queue sizes allow a new message to be queued
530       if one byte remains below the max. So you can in fact exceed the max by
531       max_message_size.
532
533       max_completed_connections divided by max_connections_per_user is the
534       number of users that can work together to denial-of-service all other
535       users by using up all connections on the systemwide bus.
536
537       Limits are normally only of interest on the systemwide bus, not the
538       user session buses.
539
540       ·   <policy>
541
542       The <policy> element defines a security policy to be applied to a
543       particular set of connections to the bus. A policy is made up of
544       <allow> and <deny> elements. Policies are normally used with the
545       systemwide bus; they are analogous to a firewall in that they allow
546       expected traffic and prevent unexpected traffic.
547
548       Currently, the system bus has a default-deny policy for sending method
549       calls and owning bus names, and a default-allow policy for receiving
550       messages, sending signals, and sending a single success or error reply
551       for each method call that does not have the NO_REPLY flag. Sending more
552       than the expected number of replies is not allowed.
553
554       In general, it is best to keep system services as small, targeted
555       programs which run in their own process and provide a single bus name.
556       Then, all that is needed is an <allow> rule for the "own" permission to
557       let the process claim the bus name, and a "send_destination" rule to
558       allow traffic from some or all uids to your service.
559
560       The <policy> element has one of four attributes:
561
562             context="(default|mandatory)"
563             at_console="(true|false)"
564             user="username or userid"
565             group="group name or gid"
566
567       Policies are applied to a connection as follows:
568
569              - all context="default" policies are applied
570              - all group="connection's user's group" policies are applied
571                in undefined order
572              - all user="connection's auth user" policies are applied
573                in undefined order
574              - all at_console="true" policies are applied
575              - all at_console="false" policies are applied
576              - all context="mandatory" policies are applied
577
578       Policies applied later will override those applied earlier, when the
579       policies overlap. Multiple policies with the same user/group/context
580       are applied in the order they appear in the config file.
581
582       <deny>
583           <allow>
584
585       A <deny> element appears below a <policy> element and prohibits some
586       action. The <allow> element makes an exception to previous <deny>
587       statements, and works just like <deny> but with the inverse meaning.
588
589       The possible attributes of these elements are:
590
591              send_interface="interface_name" | "*"
592              send_member="method_or_signal_name" | "*"
593              send_error="error_name" | "*"
594              send_broadcast="true" | "false"
595              send_destination="name" | "*"
596              send_type="method_call" | "method_return" | "signal" | "error" | "*"
597              send_path="/path/name" | "*"
598
599              receive_interface="interface_name" | "*"
600              receive_member="method_or_signal_name" | "*"
601              receive_error="error_name" | "*"
602              receive_sender="name" | "*"
603              receive_type="method_call" | "method_return" | "signal" | "error" | "*"
604              receive_path="/path/name" | "*"
605
606              send_requested_reply="true" | "false"
607              receive_requested_reply="true" | "false"
608
609              eavesdrop="true" | "false"
610
611              own="name" | "*"
612              own_prefix="name"
613              user="username" | "*"
614              group="groupname" | "*"
615
616       Examples:
617
618              <deny send_destination="org.freedesktop.Service" send_interface="org.freedesktop.System" send_member="Reboot"/>
619              <deny send_destination="org.freedesktop.System"/>
620              <deny receive_sender="org.freedesktop.System"/>
621              <deny user="john"/>
622              <deny group="enemies"/>
623
624       The <deny> element's attributes determine whether the deny "matches" a
625       particular action. If it matches, the action is denied (unless later
626       rules in the config file allow it).
627
628       Rules with one or more of the send_* family of attributes are checked
629       in order when a connection attempts to send a message. The last rule
630       that matches the message determines whether it may be sent. The
631       well-known session bus normally allows sending any message. The
632       well-known system bus normally allows sending any signal, selected
633       method calls to the dbus-daemon, and exactly one reply to each
634       previously-sent method call (either success or an error). Either of
635       these can be overridden by configuration; on the system bus, services
636       that will receive method calls must install configuration that allows
637       them to do so, usually via rules of the form <policy
638       context="default"><allow send_destination="..."/><policy>.
639
640       Rules with one or more of the receive_* family of attributes, or with
641       the eavesdrop attribute and no others, are checked for each recipient
642       of a message (there might be more than one recipient if the message is
643       a broadcast or a connection is eavesdropping). The last rule that
644       matches the message determines whether it may be received. The
645       well-known session bus normally allows receiving any message, including
646       eavesdropping. The well-known system bus normally allows receiving any
647       message that was not eavesdropped (any unicast message addressed to the
648       recipient, and any broadcast message).
649
650       The eavesdrop, min_fds and max_fds attributes are modifiers that can be
651       applied to either send_* or receive_* rules, and are documented below.
652
653       send_destination and receive_sender rules mean that messages may not be
654       sent to or received from the *owner* of the given name, not that they
655       may not be sent *to that name*. That is, if a connection owns services
656       A, B, C, and sending to A is denied, sending to B or C will not work
657       either. As a special case, send_destination="*" matches any message
658       (whether it has a destination specified or not), and receive_sender="*"
659       similarly matches any message.
660
661       Rules with send_broadcast="true" match signal messages with no
662       destination (broadcasts). Rules with send_broadcast="false" are the
663       inverse: they match any unicast destination (unicast signals, together
664       with all method calls, replies and errors) but do not match messages
665       with no destination (broadcasts). This is not the same as
666       send_destination="*", which matches any sent message, regardless of
667       whether it has a destination or not.
668
669       The other send_* and receive_* attributes are purely textual/by-value
670       matches against the given field in the message header, except that for
671       the attributes where it is allowed, * matches any message (whether it
672       has the relevant header field or not). For example, send_interface="*"
673       matches any sent message, even if it does not contain an interface
674       header field. More complex glob matching such as foo.bar.*  is not
675       allowed.
676
677       "Eavesdropping" occurs when an application receives a message that was
678       explicitly addressed to a name the application does not own, or is a
679       reply to such a message. Eavesdropping thus only applies to messages
680       that are addressed to services and replies to such messages (i.e. it
681       does not apply to signals).
682
683       For <allow>, eavesdrop="true" indicates that the rule matches even when
684       eavesdropping. eavesdrop="false" is the default and means that the rule
685       only allows messages to go to their specified recipient. For <deny>,
686       eavesdrop="true" indicates that the rule matches only when
687       eavesdropping. eavesdrop="false" is the default for <deny> also, but
688       here it means that the rule applies always, even when not
689       eavesdropping. The eavesdrop attribute can only be combined with send
690       and receive rules (with send_* and receive_* attributes).
691
692       The [send|receive]_requested_reply attribute works similarly to the
693       eavesdrop attribute. It controls whether the <deny> or <allow> matches
694       a reply that is expected (corresponds to a previous method call
695       message). This attribute only makes sense for reply messages (errors
696       and method returns), and is ignored for other message types.
697
698       For <allow>, [send|receive]_requested_reply="true" is the default and
699       indicates that only requested replies are allowed by the rule.
700       [send|receive]_requested_reply="false" means that the rule allows any
701       reply even if unexpected.
702
703       For <deny>, [send|receive]_requested_reply="false" is the default but
704       indicates that the rule matches only when the reply was not requested.
705       [send|receive]_requested_reply="true" indicates that the rule applies
706       always, regardless of pending reply state.
707
708       The min_fds and max_fds attributes modify either send_* or receive_*
709       rules. A rule with the min_fds attribute only matches messages if they
710       have at least that many Unix file descriptors attached. Conversely, a
711       rule with the max_fds attribute only matches messages if they have no
712       more than that many file descriptors attached. In practice, rules with
713       these attributes will most commonly take the form <allow
714       send_destination="..." max_fds="0"/>, <deny send_destination="..."
715       min_fds="1"/> or <deny receive_sender="*" min_fds="1"/>.
716
717       Rules with the user or group attribute are checked when a new
718       connection to the message bus is established, and control whether the
719       connection can continue. Each of these attributes cannot be combined
720       with any other attribute. As a special case, both user="*" and
721       group="*" match any connection. If there are no rules of this form, the
722       default is to allow connections from the same user ID that owns the
723       dbus-daemon process. The well-known session bus normally uses that
724       default behaviour, while the well-known system bus normally allows any
725       connection.
726
727       Rules with the own or own_prefix attribute are checked when a
728       connection attempts to own a well-known bus names. As a special case,
729       own="*" matches any well-known bus name. The well-known session bus
730       normally allows any connection to own any name, while the well-known
731       system bus normally does not allow any connection to own any name,
732       except where allowed by further configuration. System services that
733       will own a name must install configuration that allows them to do so,
734       usually via rules of the form <policy user="some-system-user"><allow
735       own="..."/></policy>.
736
737       <allow own_prefix="a.b"/> allows you to own the name "a.b" or any name
738       whose first dot-separated elements are "a.b": in particular, you can
739       own "a.b.c" or "a.b.c.d", but not "a.bc" or "a.c". This is useful when
740       services like Telepathy and ReserveDevice define a meaning for subtrees
741       of well-known names, such as
742       org.freedesktop.Telepathy.ConnectionManager.(anything) and
743       org.freedesktop.ReserveDevice1.(anything).
744
745       It does not make sense to deny a user or group inside a <policy> for a
746       user or group; user/group denials can only be inside context="default"
747       or context="mandatory" policies.
748
749       A single <deny> rule may specify combinations of attributes such as
750       send_destination and send_interface and send_type. In this case, the
751       denial applies only if both attributes match the message being denied.
752       e.g. <deny send_interface="foo.bar" send_destination="foo.blah"/> would
753       deny messages with the given interface AND the given bus name. To get
754       an OR effect you specify multiple <deny> rules.
755
756       You can't include both send_ and receive_ attributes on the same rule,
757       since "whether the message can be sent" and "whether it can be
758       received" are evaluated separately.
759
760       Be careful with send_interface/receive_interface, because the interface
761       field in messages is optional. In particular, do NOT specify <deny
762       send_interface="org.foo.Bar"/>! This will cause no-interface messages
763       to be blocked for all services, which is almost certainly not what you
764       intended. Always use rules of the form: <deny
765       send_interface="org.foo.Bar" send_destination="org.foo.Service"/>
766
767       ·   <selinux>
768
769       The <selinux> element contains settings related to Security Enhanced
770       Linux. More details below.
771
772       ·   <associate>
773
774       An <associate> element appears below an <selinux> element and creates a
775       mapping. Right now only one kind of association is possible:
776
777              <associate own="org.freedesktop.Foobar" context="foo_t"/>
778
779       This means that if a connection asks to own the name
780       "org.freedesktop.Foobar" then the source context will be the context of
781       the connection and the target context will be "foo_t" - see the short
782       discussion of SELinux below.
783
784       Note, the context here is the target context when requesting a name,
785       NOT the context of the connection owning the name.
786
787       There's currently no way to set a default for owning any name, if we
788       add this syntax it will look like:
789
790              <associate own="*" context="foo_t"/>
791
792       If you find a reason this is useful, let the developers know. Right now
793       the default will be the security context of the bus itself.
794
795       If two <associate> elements specify the same name, the element
796       appearing later in the configuration file will be used.
797
798       ·   <apparmor>
799
800       The <apparmor> element is used to configure AppArmor mediation on the
801       bus. It can contain one attribute that specifies the mediation mode:
802
803              <apparmor mode="(enabled|disabled|required)"/>
804
805       The default mode is "enabled". In "enabled" mode, AppArmor mediation
806       will be performed if AppArmor support is available in the kernel. If it
807       is not available, dbus-daemon will start but AppArmor mediation will
808       not occur. In "disabled" mode, AppArmor mediation is disabled. In
809       "required" mode, AppArmor mediation will be enabled if AppArmor support
810       is available, otherwise dbus-daemon will refuse to start.
811
812       The AppArmor mediation mode of the bus cannot be changed after the bus
813       starts. Modifying the mode in the configuration file and sending a
814       SIGHUP signal to the daemon has no effect on the mediation mode.
815

SELINUX

817       See http://www.nsa.gov/selinux/ for full details on SELinux. Some
818       useful excerpts:
819
820       Every subject (process) and object (e.g. file, socket, IPC object, etc)
821       in the system is assigned a collection of security attributes, known as
822       a security context. A security context contains all of the security
823       attributes associated with a particular subject or object that are
824       relevant to the security policy.
825
826       In order to better encapsulate security contexts and to provide greater
827       efficiency, the policy enforcement code of SELinux typically handles
828       security identifiers (SIDs) rather than security contexts. A SID is an
829       integer that is mapped by the security server to a security context at
830       runtime.
831
832       When a security decision is required, the policy enforcement code
833       passes a pair of SIDs (typically the SID of a subject and the SID of an
834       object, but sometimes a pair of subject SIDs or a pair of object SIDs),
835       and an object security class to the security server. The object
836       security class indicates the kind of object, e.g. a process, a regular
837       file, a directory, a TCP socket, etc.
838
839       Access decisions specify whether or not a permission is granted for a
840       given pair of SIDs and class. Each object class has a set of associated
841       permissions defined to control operations on objects with that class.
842
843       D-Bus performs SELinux security checks in two places.
844
845       First, any time a message is routed from one connection to another
846       connection, the bus daemon will check permissions with the security
847       context of the first connection as source, security context of the
848       second connection as target, object class "dbus" and requested
849       permission "send_msg".
850
851       If a security context is not available for a connection (impossible
852       when using UNIX domain sockets), then the target context used is the
853       context of the bus daemon itself. There is currently no way to change
854       this default, because we're assuming that only UNIX domain sockets will
855       be used to connect to the systemwide bus. If this changes, we'll
856       probably add a way to set the default connection context.
857
858       Second, any time a connection asks to own a name, the bus daemon will
859       check permissions with the security context of the connection as
860       source, the security context specified for the name in the config file
861       as target, object class "dbus" and requested permission "acquire_svc".
862
863       The security context for a bus name is specified with the <associate>
864       element described earlier in this document. If a name has no security
865       context associated in the configuration file, the security context of
866       the bus daemon itself will be used.
867

APPARMOR

869       The AppArmor confinement context is stored when applications connect to
870       the bus. The confinement context consists of a label and a confinement
871       mode. When a security decision is required, the daemon uses the
872       confinement context to query the AppArmor policy to determine if the
873       action should be allowed or denied and if the action should be audited.
874
875       The daemon performs AppArmor security checks in three places.
876
877       First, any time a message is routed from one connection to another
878       connection, the bus daemon will check permissions with the label of the
879       first connection as source, label and/or connection name of the second
880       connection as target, along with the bus name, the path name, the
881       interface name, and the member name. Reply messages, such as
882       method_return and error messages, are implicitly allowed if they are in
883       response to a message that has already been allowed.
884
885       Second, any time a connection asks to own a name, the bus daemon will
886       check permissions with the label of the connection as source, the
887       requested name as target, along with the bus name.
888
889       Third, any time a connection attempts to eavesdrop, the bus daemon will
890       check permissions with the label of the connection as the source, along
891       with the bus name.
892
893       AppArmor rules for bus mediation are not stored in the bus
894       configuration files. They are stored in the application's AppArmor
895       profile. Please see apparmor.d(5) for more details.
896

DEBUGGING

898       If you're trying to figure out where your messages are going or why you
899       aren't getting messages, there are several things you can try.
900
901       Remember that the system bus is heavily locked down and if you haven't
902       installed a security policy file to allow your message through, it
903       won't work. For the session bus, this is not a concern.
904
905       The simplest way to figure out what's happening on the bus is to run
906       the dbus-monitor program, which comes with the D-Bus package. You can
907       also send test messages with dbus-send. These programs have their own
908       man pages.
909
910       If you want to know what the daemon itself is doing, you might consider
911       running a separate copy of the daemon to test against. This will allow
912       you to put the daemon under a debugger, or run it with verbose output,
913       without messing up your real session and system daemons.
914
915       To run a separate test copy of the daemon, for example you might open a
916       terminal and type:
917
918             DBUS_VERBOSE=1 dbus-daemon --session --print-address
919
920       The test daemon address will be printed when the daemon starts. You
921       will need to copy-and-paste this address and use it as the value of the
922       DBUS_SESSION_BUS_ADDRESS environment variable when you launch the
923       applications you want to test. This will cause those applications to
924       connect to your test bus instead of the DBUS_SESSION_BUS_ADDRESS of
925       your real session bus.
926
927       DBUS_VERBOSE=1 will have NO EFFECT unless your copy of D-Bus was
928       compiled with verbose mode enabled. This is not recommended in
929       production builds due to performance impact. You may need to rebuild
930       D-Bus if your copy was not built with debugging in mind. (DBUS_VERBOSE
931       also affects the D-Bus library and thus applications using D-Bus; it
932       may be useful to see verbose output on both the client side and from
933       the daemon.)
934
935       If you want to get fancy, you can create a custom bus configuration for
936       your test bus (see the session.conf and system.conf files that define
937       the two default configurations for example). This would allow you to
938       specify a different directory for .service files, for example.
939

AUTHOR

941       See http://www.freedesktop.org/software/dbus/doc/AUTHORS
942

BUGS

944       Please send bug reports to the D-Bus mailing list or bug tracker, see
945       http://www.freedesktop.org/software/dbus/
946

NOTES

948        1. relay connections via Secure Shell or a similar protocol
949           https://lists.freedesktop.org/archives/dbus/2018-April/017447.html
950
951
952
953D-Bus 1.12.16                     06/11/2019                    DBUS-DAEMON(1)
Impressum