Emeric Vigier | 2f62582 | 2012-08-06 11:09:52 -0400 | [diff] [blame] | 1 | .\" |
| 2 | .\" dbus-daemon manual page. |
| 3 | .\" Copyright (C) 2003,2008 Red Hat, Inc. |
| 4 | .\" |
| 5 | .TH dbus-daemon 1 |
| 6 | .SH NAME |
| 7 | dbus-daemon \- Message bus daemon |
| 8 | .SH SYNOPSIS |
| 9 | .PP |
| 10 | .B dbus-daemon |
| 11 | dbus-daemon [\-\-version] [\-\-session] [\-\-system] [\-\-config-file=FILE] |
| 12 | [\-\-print-address[=DESCRIPTOR]] [\-\-print-pid[=DESCRIPTOR]] [\-\-fork] |
| 13 | |
| 14 | .SH DESCRIPTION |
| 15 | \fIdbus-daemon\fP is the D-Bus message bus daemon. See |
| 16 | http://www.freedesktop.org/software/dbus/ for more information about |
| 17 | the big picture. D-Bus is first a library that provides one-to-one |
| 18 | communication between any two applications; \fIdbus-daemon\fP is an |
| 19 | application that uses this library to implement a message bus |
| 20 | daemon. Multiple programs connect to the message bus daemon and can |
| 21 | exchange messages with one another. |
| 22 | .PP |
| 23 | There are two standard message bus instances: the systemwide message bus |
| 24 | (installed on many systems as the "messagebus" init service) and the |
| 25 | per-user-login-session message bus (started each time a user logs in). |
| 26 | \fIdbus-daemon\fP is used for both of these instances, but with |
| 27 | a different configuration file. |
| 28 | .PP |
| 29 | The \-\-session option is equivalent to |
| 30 | "\-\-config-file=@EXPANDED_SYSCONFDIR@/dbus-1/session.conf" and the \-\-system |
| 31 | option is equivalent to |
| 32 | "\-\-config-file=@EXPANDED_SYSCONFDIR@/dbus-1/system.conf". By creating |
| 33 | additional configuration files and using the \-\-config-file option, |
| 34 | additional special-purpose message bus daemons could be created. |
| 35 | .PP |
| 36 | The systemwide daemon is normally launched by an init script, |
| 37 | standardly called simply "messagebus". |
| 38 | .PP |
| 39 | The systemwide daemon is largely used for broadcasting system events, |
| 40 | such as changes to the printer queue, or adding/removing devices. |
| 41 | .PP |
| 42 | The per-session daemon is used for various interprocess communication |
| 43 | among desktop applications (however, it is not tied to X or the GUI |
| 44 | in any way). |
| 45 | .PP |
| 46 | SIGHUP will cause the D-Bus daemon to PARTIALLY reload its |
| 47 | configuration file and to flush its user/group information caches. Some |
| 48 | configuration changes would require kicking all apps off the bus; so they will |
| 49 | only take effect if you restart the daemon. Policy changes should take effect |
| 50 | with SIGHUP. |
| 51 | |
| 52 | .SH OPTIONS |
| 53 | The following options are supported: |
| 54 | .TP |
| 55 | .I "--config-file=FILE" |
| 56 | Use the given configuration file. |
| 57 | .TP |
| 58 | .I "--fork" |
| 59 | Force the message bus to fork and become a daemon, even if |
| 60 | the configuration file does not specify that it should. |
| 61 | In most contexts the configuration file already gets this |
| 62 | right, though. |
| 63 | .I "--nofork" |
| 64 | Force the message bus not to fork and become a daemon, even if |
| 65 | the configuration file specifies that it should. |
| 66 | .TP |
| 67 | .I "--print-address[=DESCRIPTOR]" |
| 68 | Print the address of the message bus to standard output, or |
| 69 | to the given file descriptor. This is used by programs that |
| 70 | launch the message bus. |
| 71 | .TP |
| 72 | .I "--print-pid[=DESCRIPTOR]" |
| 73 | Print the process ID of the message bus to standard output, or |
| 74 | to the given file descriptor. This is used by programs that |
| 75 | launch the message bus. |
| 76 | .TP |
| 77 | .I "--session" |
| 78 | Use the standard configuration file for the per-login-session message |
| 79 | bus. |
| 80 | .TP |
| 81 | .I "--system" |
| 82 | Use the standard configuration file for the systemwide message bus. |
| 83 | .TP |
| 84 | .I "--version" |
| 85 | Print the version of the daemon. |
| 86 | .TP |
| 87 | .I "--introspect" |
| 88 | Print the introspection information for all D-Bus internal interfaces. |
| 89 | .TP |
| 90 | .I "--address[=ADDRESS]" |
| 91 | Set the address to listen on. This option overrides the address |
| 92 | configured in the configuration file. |
| 93 | .TP |
| 94 | .I "--systemd-activation" |
| 95 | Enable systemd-style service activation. Only useful in conjunction |
| 96 | with the systemd system and session manager on Linux. |
| 97 | |
| 98 | .SH CONFIGURATION FILE |
| 99 | |
| 100 | A message bus daemon has a configuration file that specializes it |
| 101 | for a particular application. For example, one configuration |
| 102 | file might set up the message bus to be a systemwide message bus, |
| 103 | while another might set it up to be a per-user-login-session bus. |
| 104 | .PP |
| 105 | The configuration file also establishes resource limits, security |
| 106 | parameters, and so forth. |
| 107 | .PP |
| 108 | The configuration file is not part of any interoperability |
| 109 | specification and its backward compatibility is not guaranteed; this |
| 110 | document is documentation, not specification. |
| 111 | .PP |
| 112 | The standard systemwide and per-session message bus setups are |
| 113 | configured in the files "@EXPANDED_SYSCONFDIR@/dbus-1/system.conf" and |
| 114 | "@EXPANDED_SYSCONFDIR@/dbus-1/session.conf". These files normally |
| 115 | <include> a system-local.conf or session-local.conf; you can put local |
| 116 | overrides in those files to avoid modifying the primary configuration |
| 117 | files. |
| 118 | |
| 119 | .PP |
| 120 | The configuration file is an XML document. It must have the following |
| 121 | doctype declaration: |
| 122 | .nf |
| 123 | |
| 124 | <!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-Bus Bus Configuration 1.0//EN" |
| 125 | "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd"> |
| 126 | |
| 127 | .fi |
| 128 | |
| 129 | .PP |
| 130 | The following elements may be present in the configuration file. |
| 131 | |
| 132 | .TP |
| 133 | .I "<busconfig>" |
| 134 | |
| 135 | .PP |
| 136 | Root element. |
| 137 | |
| 138 | .TP |
| 139 | .I "<type>" |
| 140 | |
| 141 | .PP |
| 142 | The well-known type of the message bus. Currently known values are |
| 143 | "system" and "session"; if other values are set, they should be |
| 144 | either added to the D-Bus specification, or namespaced. The last |
| 145 | <type> element "wins" (previous values are ignored). This element |
| 146 | only controls which message bus specific environment variables are |
| 147 | set in activated clients. Most of the policy that distinguishes a |
| 148 | session bus from the system bus is controlled from the other elements |
| 149 | in the configuration file. |
| 150 | |
| 151 | .PP |
| 152 | If the well-known type of the message bus is "session", then the |
| 153 | DBUS_STARTER_BUS_TYPE environment variable will be set to "session" |
| 154 | and the DBUS_SESSION_BUS_ADDRESS environment variable will be set |
| 155 | to the address of the session bus. Likewise, if the type of the |
| 156 | message bus is "system", then the DBUS_STARTER_BUS_TYPE environment |
| 157 | variable will be set to "system" and the DBUS_SESSION_BUS_ADDRESS |
| 158 | environment variable will be set to the address of the system bus |
| 159 | (which is normally well known anyway). |
| 160 | |
| 161 | .PP |
| 162 | Example: <type>session</type> |
| 163 | |
| 164 | .TP |
| 165 | .I "<include>" |
| 166 | |
| 167 | .PP |
| 168 | Include a file <include>filename.conf</include> at this point. If the |
| 169 | filename is relative, it is located relative to the configuration file |
| 170 | doing the including. |
| 171 | |
| 172 | .PP |
| 173 | <include> has an optional attribute "ignore_missing=(yes|no)" |
| 174 | which defaults to "no" if not provided. This attribute |
| 175 | controls whether it's a fatal error for the included file |
| 176 | to be absent. |
| 177 | |
| 178 | .TP |
| 179 | .I "<includedir>" |
| 180 | |
| 181 | .PP |
| 182 | Include all files in <includedir>foo.d</includedir> at this |
| 183 | point. Files in the directory are included in undefined order. |
| 184 | Only files ending in ".conf" are included. |
| 185 | |
| 186 | .PP |
| 187 | This is intended to allow extension of the system bus by particular |
| 188 | packages. For example, if CUPS wants to be able to send out |
| 189 | notification of printer queue changes, it could install a file to |
| 190 | @EXPANDED_SYSCONFDIR@/dbus-1/system.d that allowed all apps to receive |
| 191 | this message and allowed the printer daemon user to send it. |
| 192 | |
| 193 | .TP |
| 194 | .I "<user>" |
| 195 | |
| 196 | .PP |
| 197 | The user account the daemon should run as, as either a username or a |
| 198 | UID. If the daemon cannot change to this UID on startup, it will exit. |
| 199 | If this element is not present, the daemon will not change or care |
| 200 | about its UID. |
| 201 | |
| 202 | .PP |
| 203 | The last <user> entry in the file "wins", the others are ignored. |
| 204 | |
| 205 | .PP |
| 206 | The user is changed after the bus has completed initialization. So |
| 207 | sockets etc. will be created before changing user, but no data will be |
| 208 | read from clients before changing user. This means that sockets |
| 209 | and PID files can be created in a location that requires root |
| 210 | privileges for writing. |
| 211 | |
| 212 | .TP |
| 213 | .I "<fork>" |
| 214 | |
| 215 | .PP |
| 216 | If present, the bus daemon becomes a real daemon (forks |
| 217 | into the background, etc.). This is generally used |
| 218 | rather than the \-\-fork command line option. |
| 219 | |
| 220 | .TP |
| 221 | .I "<keep_umask>" |
| 222 | |
| 223 | .PP |
| 224 | If present, the bus daemon keeps its original umask when forking. |
| 225 | This may be useful to avoid affecting the behavior of child processes. |
| 226 | |
| 227 | .TP |
| 228 | .I "<listen>" |
| 229 | |
| 230 | .PP |
| 231 | Add an address that the bus should listen on. The |
| 232 | address is in the standard D-Bus format that contains |
| 233 | a transport name plus possible parameters/options. |
| 234 | |
| 235 | .PP |
| 236 | Example: <listen>unix:path=/tmp/foo</listen> |
| 237 | |
| 238 | .PP |
| 239 | Example: <listen>tcp:host=localhost,port=1234</listen> |
| 240 | |
| 241 | .PP |
| 242 | If there are multiple <listen> elements, then the bus listens |
| 243 | on multiple addresses. The bus will pass its address to |
| 244 | started services or other interested parties with |
| 245 | the last address given in <listen> first. That is, |
| 246 | apps will try to connect to the last <listen> address first. |
| 247 | |
| 248 | .PP |
| 249 | tcp sockets can accept IPv4 addresses, IPv6 addresses or hostnames. |
| 250 | If a hostname resolves to multiple addresses, the server will bind |
| 251 | to all of them. The family=ipv4 or family=ipv6 options can be used |
| 252 | to force it to bind to a subset of addresses |
| 253 | |
| 254 | .PP |
| 255 | Example: <listen>tcp:host=localhost,port=0,family=ipv4</listen> |
| 256 | |
| 257 | .PP |
| 258 | A special case is using a port number of zero (or omitting the port), |
| 259 | which means to choose an available port selected by the operating |
| 260 | system. The port number chosen can be obtained with the |
| 261 | --print-address command line parameter and will be present in other |
| 262 | cases where the server reports its own address, such as when |
| 263 | DBUS_SESSION_BUS_ADDRESS is set. |
| 264 | |
| 265 | .PP |
| 266 | Example: <listen>tcp:host=localhost,port=0</listen> |
| 267 | |
| 268 | .PP |
| 269 | tcp addresses also allow a bind=hostname option, which will override |
| 270 | the host option specifying what address to bind to, without changing |
| 271 | the address reported by the bus. The bind option can also take a |
| 272 | special name '*' to cause the bus to listen on all local address |
| 273 | (INADDR_ANY). The specified host should be a valid name of the local |
| 274 | machine or weird stuff will happen. |
| 275 | |
| 276 | .PP |
| 277 | Example: <listen>tcp:host=localhost,bind=*,port=0</listen> |
| 278 | |
| 279 | .TP |
| 280 | .I "<auth>" |
| 281 | |
| 282 | .PP |
| 283 | Lists permitted authorization mechanisms. If this element doesn't |
| 284 | exist, then all known mechanisms are allowed. If there are multiple |
| 285 | <auth> elements, all the listed mechanisms are allowed. The order in |
| 286 | which mechanisms are listed is not meaningful. |
| 287 | |
| 288 | .PP |
| 289 | Example: <auth>EXTERNAL</auth> |
| 290 | |
| 291 | .PP |
| 292 | Example: <auth>DBUS_COOKIE_SHA1</auth> |
| 293 | |
| 294 | .TP |
| 295 | .I "<servicedir>" |
| 296 | |
| 297 | .PP |
| 298 | Adds a directory to scan for .service files. Directories are |
| 299 | scanned starting with the last to appear in the config file |
| 300 | (the first .service file found that provides a particular |
| 301 | service will be used). |
| 302 | |
| 303 | .PP |
| 304 | Service files tell the bus how to automatically start a program. |
| 305 | They are primarily used with the per-user-session bus, |
| 306 | not the systemwide bus. |
| 307 | |
| 308 | .TP |
| 309 | .I "<standard_session_servicedirs/>" |
| 310 | |
| 311 | .PP |
| 312 | <standard_session_servicedirs/> is equivalent to specifying a series |
| 313 | of <servicedir/> elements for each of the data directories in the "XDG |
| 314 | Base Directory Specification" with the subdirectory "dbus-1/services", |
| 315 | so for example "/usr/share/dbus-1/services" would be among the |
| 316 | directories searched. |
| 317 | |
| 318 | .PP |
| 319 | The "XDG Base Directory Specification" can be found at |
| 320 | http://freedesktop.org/wiki/Standards/basedir-spec if it hasn't moved, |
| 321 | otherwise try your favorite search engine. |
| 322 | |
| 323 | .PP |
| 324 | The <standard_session_servicedirs/> option is only relevant to the |
| 325 | per-user-session bus daemon defined in |
| 326 | @EXPANDED_SYSCONFDIR@/dbus-1/session.conf. Putting it in any other |
| 327 | configuration file would probably be nonsense. |
| 328 | |
| 329 | .TP |
| 330 | .I "<standard_system_servicedirs/>" |
| 331 | |
| 332 | .PP |
| 333 | <standard_system_servicedirs/> specifies the standard system-wide |
| 334 | activation directories that should be searched for service files. |
| 335 | This option defaults to @EXPANDED_DATADIR@/dbus-1/system-services. |
| 336 | |
| 337 | .PP |
| 338 | The <standard_system_servicedirs/> option is only relevant to the |
| 339 | per-system bus daemon defined in |
| 340 | @EXPANDED_SYSCONFDIR@/dbus-1/system.conf. Putting it in any other |
| 341 | configuration file would probably be nonsense. |
| 342 | |
| 343 | .TP |
| 344 | .I "<servicehelper/>" |
| 345 | |
| 346 | .PP |
| 347 | <servicehelper/> specifies the setuid helper that is used to launch |
| 348 | system daemons with an alternate user. Typically this should be |
| 349 | the dbus-daemon-launch-helper executable in located in libexec. |
| 350 | |
| 351 | .PP |
| 352 | The <servicehelper/> option is only relevant to the per-system bus daemon |
| 353 | defined in @EXPANDED_SYSCONFDIR@/dbus-1/system.conf. Putting it in any other |
| 354 | configuration file would probably be nonsense. |
| 355 | |
| 356 | .TP |
| 357 | .I "<limit>" |
| 358 | |
| 359 | .PP |
| 360 | <limit> establishes a resource limit. For example: |
| 361 | .nf |
| 362 | <limit name="max_message_size">64</limit> |
| 363 | <limit name="max_completed_connections">512</limit> |
| 364 | .fi |
| 365 | |
| 366 | .PP |
| 367 | The name attribute is mandatory. |
| 368 | Available limit names are: |
| 369 | .nf |
| 370 | "max_incoming_bytes" : total size in bytes of messages |
| 371 | incoming from a single connection |
| 372 | "max_incoming_unix_fds" : total number of unix fds of messages |
| 373 | incoming from a single connection |
| 374 | "max_outgoing_bytes" : total size in bytes of messages |
| 375 | queued up for a single connection |
| 376 | "max_outgoing_unix_fds" : total number of unix fds of messages |
| 377 | queued up for a single connection |
| 378 | "max_message_size" : max size of a single message in |
| 379 | bytes |
| 380 | "max_message_unix_fds" : max unix fds of a single message |
| 381 | "service_start_timeout" : milliseconds (thousandths) until |
| 382 | a started service has to connect |
| 383 | "auth_timeout" : milliseconds (thousandths) a |
| 384 | connection is given to |
| 385 | authenticate |
| 386 | "max_completed_connections" : max number of authenticated connections |
| 387 | "max_incomplete_connections" : max number of unauthenticated |
| 388 | connections |
| 389 | "max_connections_per_user" : max number of completed connections from |
| 390 | the same user |
| 391 | "max_pending_service_starts" : max number of service launches in |
| 392 | progress at the same time |
| 393 | "max_names_per_connection" : max number of names a single |
| 394 | connection can own |
| 395 | "max_match_rules_per_connection": max number of match rules for a single |
| 396 | connection |
| 397 | "max_replies_per_connection" : max number of pending method |
| 398 | replies per connection |
| 399 | (number of calls-in-progress) |
| 400 | "reply_timeout" : milliseconds (thousandths) |
| 401 | until a method call times out |
| 402 | .fi |
| 403 | |
| 404 | .PP |
| 405 | The max incoming/outgoing queue sizes allow a new message to be queued |
| 406 | if one byte remains below the max. So you can in fact exceed the max |
| 407 | by max_message_size. |
| 408 | |
| 409 | .PP |
| 410 | max_completed_connections divided by max_connections_per_user is the |
| 411 | number of users that can work together to denial-of-service all other users by using |
| 412 | up all connections on the systemwide bus. |
| 413 | |
| 414 | .PP |
| 415 | Limits are normally only of interest on the systemwide bus, not the user session |
| 416 | buses. |
| 417 | |
| 418 | .TP |
| 419 | .I "<policy>" |
| 420 | |
| 421 | .PP |
| 422 | The <policy> element defines a security policy to be applied to a particular |
| 423 | set of connections to the bus. A policy is made up of |
| 424 | <allow> and <deny> elements. Policies are normally used with the systemwide bus; |
| 425 | they are analogous to a firewall in that they allow expected traffic |
| 426 | and prevent unexpected traffic. |
| 427 | |
| 428 | .PP |
| 429 | Currently, the system bus has a default-deny policy for sending method calls |
| 430 | and owning bus names. Everything else, in particular reply messages, receive |
| 431 | checks, and signals has a default allow policy. |
| 432 | |
| 433 | .PP |
| 434 | In general, it is best to keep system services as small, targeted programs which |
| 435 | run in their own process and provide a single bus name. Then, all that is needed |
| 436 | is an <allow> rule for the "own" permission to let the process claim the bus |
| 437 | name, and a "send_destination" rule to allow traffic from some or all uids to |
| 438 | your service. |
| 439 | |
| 440 | .PP |
| 441 | The <policy> element has one of four attributes: |
| 442 | .nf |
| 443 | context="(default|mandatory)" |
| 444 | at_console="(true|false)" |
| 445 | user="username or userid" |
| 446 | group="group name or gid" |
| 447 | .fi |
| 448 | |
| 449 | .PP |
| 450 | Policies are applied to a connection as follows: |
| 451 | .nf |
| 452 | - all context="default" policies are applied |
| 453 | - all group="connection's user's group" policies are applied |
| 454 | in undefined order |
| 455 | - all user="connection's auth user" policies are applied |
| 456 | in undefined order |
| 457 | - all at_console="true" policies are applied |
| 458 | - all at_console="false" policies are applied |
| 459 | - all context="mandatory" policies are applied |
| 460 | .fi |
| 461 | |
| 462 | .PP |
| 463 | Policies applied later will override those applied earlier, |
| 464 | when the policies overlap. Multiple policies with the same |
| 465 | user/group/context are applied in the order they appear |
| 466 | in the config file. |
| 467 | |
| 468 | .TP |
| 469 | .I "<deny>" |
| 470 | .I "<allow>" |
| 471 | |
| 472 | .PP |
| 473 | A <deny> element appears below a <policy> element and prohibits some |
| 474 | action. The <allow> element makes an exception to previous <deny> |
| 475 | statements, and works just like <deny> but with the inverse meaning. |
| 476 | |
| 477 | .PP |
| 478 | The possible attributes of these elements are: |
| 479 | .nf |
| 480 | send_interface="interface_name" |
| 481 | send_member="method_or_signal_name" |
| 482 | send_error="error_name" |
| 483 | send_destination="name" |
| 484 | send_type="method_call" | "method_return" | "signal" | "error" |
| 485 | send_path="/path/name" |
| 486 | |
| 487 | receive_interface="interface_name" |
| 488 | receive_member="method_or_signal_name" |
| 489 | receive_error="error_name" |
| 490 | receive_sender="name" |
| 491 | receive_type="method_call" | "method_return" | "signal" | "error" |
| 492 | receive_path="/path/name" |
| 493 | |
| 494 | send_requested_reply="true" | "false" |
| 495 | receive_requested_reply="true" | "false" |
| 496 | |
| 497 | eavesdrop="true" | "false" |
| 498 | |
| 499 | own="name" |
| 500 | user="username" |
| 501 | group="groupname" |
| 502 | .fi |
| 503 | |
| 504 | .PP |
| 505 | Examples: |
| 506 | .nf |
| 507 | <deny send_destination="org.freedesktop.Service" send_interface="org.freedesktop.System" send_member="Reboot"/> |
| 508 | <deny send_destination="org.freedesktop.System"/> |
| 509 | <deny receive_sender="org.freedesktop.System"/> |
| 510 | <deny user="john"/> |
| 511 | <deny group="enemies"/> |
| 512 | .fi |
| 513 | |
| 514 | .PP |
| 515 | The <deny> element's attributes determine whether the deny "matches" a |
| 516 | particular action. If it matches, the action is denied (unless later |
| 517 | rules in the config file allow it). |
| 518 | .PP |
| 519 | send_destination and receive_sender rules mean that messages may not be |
| 520 | sent to or received from the *owner* of the given name, not that |
| 521 | they may not be sent *to that name*. That is, if a connection |
| 522 | owns services A, B, C, and sending to A is denied, sending to B or C |
| 523 | will not work either. |
| 524 | .PP |
| 525 | The other send_* and receive_* attributes are purely textual/by-value |
| 526 | matches against the given field in the message header. |
| 527 | .PP |
| 528 | "Eavesdropping" occurs when an application receives a message that |
| 529 | was explicitly addressed to a name the application does not own, or |
| 530 | is a reply to such a message. Eavesdropping thus only applies to |
| 531 | messages that are addressed to services and replies to such messages |
| 532 | (i.e. it does not apply to signals). |
| 533 | .PP |
| 534 | For <allow>, eavesdrop="true" indicates that the rule matches even |
| 535 | when eavesdropping. eavesdrop="false" is the default and means that |
| 536 | the rule only allows messages to go to their specified recipient. |
| 537 | For <deny>, eavesdrop="true" indicates that the rule matches |
| 538 | only when eavesdropping. eavesdrop="false" is the default for <deny> |
| 539 | also, but here it means that the rule applies always, even when |
| 540 | not eavesdropping. The eavesdrop attribute can only be combined with |
| 541 | send and receive rules (with send_* and receive_* attributes). |
| 542 | .PP |
| 543 | The [send|receive]_requested_reply attribute works similarly to the eavesdrop |
| 544 | attribute. It controls whether the <deny> or <allow> matches a reply |
| 545 | that is expected (corresponds to a previous method call message). |
| 546 | This attribute only makes sense for reply messages (errors and method |
| 547 | returns), and is ignored for other message types. |
| 548 | |
| 549 | .PP |
| 550 | For <allow>, [send|receive]_requested_reply="true" is the default and indicates that |
| 551 | only requested replies are allowed by the |
| 552 | rule. [send|receive]_requested_reply="false" means that the rule allows any reply |
| 553 | even if unexpected. |
| 554 | |
| 555 | .PP |
| 556 | For <deny>, [send|receive]_requested_reply="false" is the default but indicates that |
| 557 | the rule matches only when the reply was not |
| 558 | requested. [send|receive]_requested_reply="true" indicates that the rule applies |
| 559 | always, regardless of pending reply state. |
| 560 | |
| 561 | .PP |
| 562 | user and group denials mean that the given user or group may |
| 563 | not connect to the message bus. |
| 564 | |
| 565 | .PP |
| 566 | For "name", "username", "groupname", etc. |
| 567 | the character "*" can be substituted, meaning "any." Complex globs |
| 568 | like "foo.bar.*" aren't allowed for now because they'd be work to |
| 569 | implement and maybe encourage sloppy security anyway. |
| 570 | |
| 571 | .PP |
| 572 | It does not make sense to deny a user or group inside a <policy> |
| 573 | for a user or group; user/group denials can only be inside |
| 574 | context="default" or context="mandatory" policies. |
| 575 | |
| 576 | .PP |
| 577 | A single <deny> rule may specify combinations of attributes such as |
| 578 | send_destination and send_interface and send_type. In this case, the |
| 579 | denial applies only if both attributes match the message being denied. |
| 580 | e.g. <deny send_interface="foo.bar" send_destination="foo.blah"/> would |
| 581 | deny messages with the given interface AND the given bus name. |
| 582 | To get an OR effect you specify multiple <deny> rules. |
| 583 | |
| 584 | .PP |
| 585 | You can't include both send_ and receive_ attributes on the same |
| 586 | rule, since "whether the message can be sent" and "whether it can be |
| 587 | received" are evaluated separately. |
| 588 | |
| 589 | .PP |
| 590 | Be careful with send_interface/receive_interface, because the |
| 591 | interface field in messages is optional. In particular, do NOT |
| 592 | specify <deny send_interface="org.foo.Bar"/>! This will cause |
| 593 | no-interface messages to be blocked for all services, which is |
| 594 | almost certainly not what you intended. Always use rules of |
| 595 | the form: <deny send_interface="org.foo.Bar" send_destination="org.foo.Service"/> |
| 596 | |
| 597 | .TP |
| 598 | .I "<selinux>" |
| 599 | |
| 600 | .PP |
| 601 | The <selinux> element contains settings related to Security Enhanced Linux. |
| 602 | More details below. |
| 603 | |
| 604 | .TP |
| 605 | .I "<associate>" |
| 606 | |
| 607 | .PP |
| 608 | An <associate> element appears below an <selinux> element and |
| 609 | creates a mapping. Right now only one kind of association is possible: |
| 610 | .nf |
| 611 | <associate own="org.freedesktop.Foobar" context="foo_t"/> |
| 612 | .fi |
| 613 | |
| 614 | .PP |
| 615 | This means that if a connection asks to own the name |
| 616 | "org.freedesktop.Foobar" then the source context will be the context |
| 617 | of the connection and the target context will be "foo_t" - see the |
| 618 | short discussion of SELinux below. |
| 619 | |
| 620 | .PP |
| 621 | Note, the context here is the target context when requesting a name, |
| 622 | NOT the context of the connection owning the name. |
| 623 | |
| 624 | .PP |
| 625 | There's currently no way to set a default for owning any name, if |
| 626 | we add this syntax it will look like: |
| 627 | .nf |
| 628 | <associate own="*" context="foo_t"/> |
| 629 | .fi |
| 630 | If you find a reason this is useful, let the developers know. |
| 631 | Right now the default will be the security context of the bus itself. |
| 632 | |
| 633 | .PP |
| 634 | If two <associate> elements specify the same name, the element |
| 635 | appearing later in the configuration file will be used. |
| 636 | |
| 637 | .SH SELinux |
| 638 | |
| 639 | .PP |
| 640 | See http://www.nsa.gov/selinux/ for full details on SELinux. Some useful excerpts: |
| 641 | |
| 642 | .IP "" 8 |
| 643 | Every subject (process) and object (e.g. file, socket, IPC object, |
| 644 | etc) in the system is assigned a collection of security attributes, |
| 645 | known as a security context. A security context contains all of the |
| 646 | security attributes associated with a particular subject or object |
| 647 | that are relevant to the security policy. |
| 648 | |
| 649 | .IP "" 8 |
| 650 | In order to better encapsulate security contexts and to provide |
| 651 | greater efficiency, the policy enforcement code of SELinux typically |
| 652 | handles security identifiers (SIDs) rather than security contexts. A |
| 653 | SID is an integer that is mapped by the security server to a security |
| 654 | context at runtime. |
| 655 | |
| 656 | .IP "" 8 |
| 657 | When a security decision is required, the policy enforcement code |
| 658 | passes a pair of SIDs (typically the SID of a subject and the SID of |
| 659 | an object, but sometimes a pair of subject SIDs or a pair of object |
| 660 | SIDs), and an object security class to the security server. The object |
| 661 | security class indicates the kind of object, e.g. a process, a regular |
| 662 | file, a directory, a TCP socket, etc. |
| 663 | |
| 664 | .IP "" 8 |
| 665 | Access decisions specify whether or not a permission is granted for a |
| 666 | given pair of SIDs and class. Each object class has a set of |
| 667 | associated permissions defined to control operations on objects with |
| 668 | that class. |
| 669 | |
| 670 | .PP |
| 671 | D-Bus performs SELinux security checks in two places. |
| 672 | |
| 673 | .PP |
| 674 | First, any time a message is routed from one connection to another |
| 675 | connection, the bus daemon will check permissions with the security context of |
| 676 | the first connection as source, security context of the second connection |
| 677 | as target, object class "dbus" and requested permission "send_msg". |
| 678 | |
| 679 | .PP |
| 680 | If a security context is not available for a connection |
| 681 | (impossible when using UNIX domain sockets), then the target |
| 682 | context used is the context of the bus daemon itself. |
| 683 | There is currently no way to change this default, because we're |
| 684 | assuming that only UNIX domain sockets will be used to |
| 685 | connect to the systemwide bus. If this changes, we'll |
| 686 | probably add a way to set the default connection context. |
| 687 | |
| 688 | .PP |
| 689 | Second, any time a connection asks to own a name, |
| 690 | the bus daemon will check permissions with the security |
| 691 | context of the connection as source, the security context specified |
| 692 | for the name in the config file as target, object |
| 693 | class "dbus" and requested permission "acquire_svc". |
| 694 | |
| 695 | .PP |
| 696 | The security context for a bus name is specified with the |
| 697 | <associate> element described earlier in this document. |
| 698 | If a name has no security context associated in the |
| 699 | configuration file, the security context of the bus daemon |
| 700 | itself will be used. |
| 701 | |
| 702 | .SH DEBUGGING |
| 703 | |
| 704 | .PP |
| 705 | If you're trying to figure out where your messages are going or why |
| 706 | you aren't getting messages, there are several things you can try. |
| 707 | .PP |
| 708 | Remember that the system bus is heavily locked down and if you |
| 709 | haven't installed a security policy file to allow your message |
| 710 | through, it won't work. For the session bus, this is not a concern. |
| 711 | .PP |
| 712 | The simplest way to figure out what's happening on the bus is to run |
| 713 | the \fIdbus-monitor\fP program, which comes with the D-Bus |
| 714 | package. You can also send test messages with \fIdbus-send\fP. These |
| 715 | programs have their own man pages. |
| 716 | .PP |
| 717 | If you want to know what the daemon itself is doing, you might consider |
| 718 | running a separate copy of the daemon to test against. This will allow you |
| 719 | to put the daemon under a debugger, or run it with verbose output, without |
| 720 | messing up your real session and system daemons. |
| 721 | .PP |
| 722 | To run a separate test copy of the daemon, for example you might open a terminal |
| 723 | and type: |
| 724 | .nf |
| 725 | DBUS_VERBOSE=1 dbus-daemon --session --print-address |
| 726 | .fi |
| 727 | .PP |
| 728 | The test daemon address will be printed when the daemon starts. You will need |
| 729 | to copy-and-paste this address and use it as the value of the |
| 730 | DBUS_SESSION_BUS_ADDRESS environment variable when you launch the applications |
| 731 | you want to test. This will cause those applications to connect to your |
| 732 | test bus instead of the DBUS_SESSION_BUS_ADDRESS of your real session bus. |
| 733 | .PP |
| 734 | DBUS_VERBOSE=1 will have NO EFFECT unless your copy of D-Bus |
| 735 | was compiled with verbose mode enabled. This is not recommended in |
| 736 | production builds due to performance impact. You may need to rebuild |
| 737 | D-Bus if your copy was not built with debugging in mind. (DBUS_VERBOSE |
| 738 | also affects the D-Bus library and thus applications using D-Bus; it may |
| 739 | be useful to see verbose output on both the client side and from the daemon.) |
| 740 | .PP |
| 741 | If you want to get fancy, you can create a custom bus |
| 742 | configuration for your test bus (see the session.conf and system.conf |
| 743 | files that define the two default configurations for example). This |
| 744 | would allow you to specify a different directory for .service files, |
| 745 | for example. |
| 746 | |
| 747 | .SH AUTHOR |
| 748 | See http://www.freedesktop.org/software/dbus/doc/AUTHORS |
| 749 | |
| 750 | .SH BUGS |
| 751 | Please send bug reports to the D-Bus mailing list or bug tracker, |
| 752 | see http://www.freedesktop.org/software/dbus/ |