1: .\" 2: .\" dbus-daemon manual page. 3: .\" Copyright (C) 2003 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: 16: \fIdbus-daemon\fP is the D-Bus message bus daemon. See 17: http://www.freedesktop.org/software/dbus/ for more information about 18: the big picture. D-Bus is first a library that provides one-to-one 19: communication between any two applications; \fIdbus-daemon\fP is an 20: application that uses this library to implement a message bus 21: daemon. Multiple programs connect to the message bus daemon and can 22: exchange messages with one another. 23: 24: .PP 25: There are two standard message bus instances: the systemwide message bus 26: (installed on many systems as the "messagebus" init service) and the 27: per-user-login-session message bus (started each time a user logs in). 28: \fIdbus-daemon\fP is used for both of these instances, but with 29: a different configuration file. 30: 31: .PP 32: The \-\-session option is equivalent to 33: "\-\-config-file=/usr/local/etc/dbus-1/session.conf" and the \-\-system 34: option is equivalent to 35: "\-\-config-file=/usr/local/etc/dbus-1/system.conf". By creating 36: additional configuration files and using the \-\-config-file option, 37: additional special-purpose message bus daemons could be created. 38: 39: .PP 40: The systemwide daemon is normally launched by an init script, 41: standardly called simply "messagebus". 42: 43: .PP 44: The systemwide daemon is largely used for broadcasting system events, 45: such as changes to the printer queue, or adding/removing devices. 46: 47: .PP 48: The per-session daemon is used for various interprocess communication 49: among desktop applications (however, it is not tied to X or the GUI 50: in any way). 51: 52: .PP 53: SIGHUP will cause the D-Bus daemon to PARTIALLY reload its 54: configuration file and to flush its user/group information caches. Some 55: configuration changes would require kicking all apps off the bus; so they will 56: only take effect if you restart the daemon. Policy changes should take effect 57: with SIGHUP. 58: 59: .SH OPTIONS 60: The following options are supported: 61: .TP 62: .I "--config-file=FILE" 63: Use the given configuration file. 64: .TP 65: .I "--fork" 66: Force the message bus to fork and become a daemon, even if 67: the configuration file does not specify that it should. 68: In most contexts the configuration file already gets this 69: right, though. 70: .TP 71: .I "--print-address[=DESCRIPTOR]" 72: Print the address of the message bus to standard output, or 73: to the given file descriptor. This is used by programs that 74: launch the message bus. 75: .TP 76: .I "--print-pid[=DESCRIPTOR]" 77: Print the process ID of the message bus to standard output, or 78: to the given file descriptor. This is used by programs that 79: launch the message bus. 80: .TP 81: .I "--session" 82: Use the standard configuration file for the per-login-session message 83: bus. 84: .TP 85: .I "--system" 86: Use the standard configuration file for the systemwide message bus. 87: .TP 88: .I "--version" 89: Print the version of the daemon. 90: 91: .SH CONFIGURATION FILE 92: 93: A message bus daemon has a configuration file that specializes it 94: for a particular application. For example, one configuration 95: file might set up the message bus to be a systemwide message bus, 96: while another might set it up to be a per-user-login-session bus. 97: 98: .PP 99: The configuration file also establishes resource limits, security 100: parameters, and so forth. 101: 102: .PP 103: The configuration file is not part of any interoperability 104: specification and its backward compatibility is not guaranteed; this 105: document is documentation, not specification. 106: 107: .PP 108: The standard systemwide and per-session message bus setups are 109: configured in the files "/usr/local/etc/dbus-1/system.conf" and 110: "/usr/local/etc/dbus-1/session.conf". These files normally 111: <include> a system-local.conf or session-local.conf; you can put local 112: overrides in those files to avoid modifying the primary configuration 113: files. 114: 115: .PP 116: The configuration file is an XML document. It must have the following 117: doctype declaration: 118: .nf 119: 120: <!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-Bus Bus Configuration 1.0//EN" 121: "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd"> 122: 123: .fi 124: 125: .PP 126: The following elements may be present in the configuration file. 127: 128: .TP 129: .I "<busconfig>" 130: 131: .PP 132: Root element. 133: 134: .TP 135: .I "<type>" 136: 137: .PP 138: The well-known type of the message bus. Currently known values are 139: "system" and "session"; if other values are set, they should be 140: either added to the D-Bus specification, or namespaced. The last 141: <type> element "wins" (previous values are ignored). 142: 143: .PP 144: Example: <type>session</type> 145: 146: .TP 147: .I "<include>" 148: 149: .PP 150: Include a file <include>filename.conf</include> at this point. If the 151: filename is relative, it is located relative to the configuration file 152: doing the including. 153: 154: .PP 155: <include> has an optional attribute "ignore_missing=(yes|no)" 156: which defaults to "no" if not provided. This attribute 157: controls whether it's a fatal error for the included file 158: to be absent. 159: 160: .TP 161: .I "<includedir>" 162: 163: .PP 164: Include all files in <includedir>foo.d</includedir> at this 165: point. Files in the directory are included in undefined order. 166: Only files ending in ".conf" are included. 167: 168: .PP 169: This is intended to allow extension of the system bus by particular 170: packages. For example, if CUPS wants to be able to send out 171: notification of printer queue changes, it could install a file to 172: /usr/local/etc/dbus-1/system.d that allowed all apps to receive 173: this message and allowed the printer daemon user to send it. 174: 175: .TP 176: .I "<user>" 177: 178: .PP 179: The user account the daemon should run as, as either a username or a 180: UID. If the daemon cannot change to this UID on startup, it will exit. 181: If this element is not present, the daemon will not change or care 182: about its UID. 183: 184: .PP 185: The last <user> entry in the file "wins", the others are ignored. 186: 187: .PP 188: The user is changed after the bus has completed initialization. So 189: sockets etc. will be created before changing user, but no data will be 190: read from clients before changing user. This means that sockets 191: and PID files can be created in a location that requires root 192: privileges for writing. 193: 194: .TP 195: .I "<fork>" 196: 197: .PP 198: If present, the bus daemon becomes a real daemon (forks 199: into the background, etc.). This is generally used 200: rather than the \-\-fork command line option. 201: 202: .TP 203: .I "<listen>" 204: 205: .PP 206: Add an address that the bus should listen on. The 207: address is in the standard D-Bus format that contains 208: a transport name plus possible parameters/options. 209: 210: .PP 211: Example: <listen>unix:path=/tmp/foo</listen> 212: 213: .PP 214: If there are multiple <listen> elements, then the bus listens 215: on multiple addresses. The bus will pass its address to 216: started services or other interested parties with 217: the last address given in <listen> first. That is, 218: apps will try to connect to the last <listen> address first. 219: 220: .TP 221: .I "<auth>" 222: 223: .PP 224: Lists permitted authorization mechanisms. If this element doesn't 225: exist, then all known mechanisms are allowed. If there are multiple 226: <auth> elements, all the listed mechanisms are allowed. The order in 227: which mechanisms are listed is not meaningful. 228: 229: .PP 230: Example: <auth>EXTERNAL</auth> 231: 232: .PP 233: Example: <auth>DBUS_COOKIE_SHA1</auth> 234: 235: .TP 236: .I "<servicedir>" 237: 238: .PP 239: Adds a directory to scan for .service files. Directories are 240: scanned starting with the last to appear in the config file 241: (the first .service file found that provides a particular 242: service will be used). 243: 244: .PP 245: Service files tell the bus how to automatically start a program. 246: They are primarily used with the per-user-session bus, 247: not the systemwide bus. 248: 249: .TP 250: .I "<standard_session_servicedirs/>" 251: 252: .PP 253: <standard_session_servicedirs/> is equivalent to specifying a series 254: of <servicedir/> elements for each of the data directories in the "XDG 255: Base Directory Specification" with the subdirectory "dbus-1/services", 256: so for example "/usr/share/dbus-1/services" would be among the 257: directories searched. 258: 259: .PP 260: The "XDG Base Directory Specification" can be found at 261: http://freedesktop.org/wiki/Standards/basedir-spec if it hasn't moved, 262: otherwise try your favorite search engine. 263: 264: .PP 265: The <standard_session_servicedirs/> option is only relevant to the 266: per-user-session bus daemon defined in 267: /usr/local/etc/dbus-1/session.conf. Putting it in any other 268: configuration file would probably be nonsense. 269: 270: .TP 271: .I "<limit>" 272: 273: .PP 274: <limit> establishes a resource limit. For example: 275: .nf 276: <limit name="max_message_size">64</limit> 277: <limit name="max_completed_connections">512</limit> 278: .fi 279: 280: .PP 281: The name attribute is mandatory. 282: Available limit names are: 283: .nf 284: "max_incoming_bytes" : total size in bytes of messages 285: incoming from a single connection 286: "max_outgoing_bytes" : total size in bytes of messages 287: queued up for a single connection 288: "max_message_size" : max size of a single message in 289: bytes 290: "service_start_timeout" : milliseconds (thousandths) until 291: a started service has to connect 292: "auth_timeout" : milliseconds (thousandths) a 293: connection is given to 294: authenticate 295: "max_completed_connections" : max number of authenticated connections 296: "max_incomplete_connections" : max number of unauthenticated 297: connections 298: "max_connections_per_user" : max number of completed connections from 299: the same user 300: "max_pending_service_starts" : max number of service launches in 301: progress at the same time 302: "max_names_per_connection" : max number of names a single 303: connection can own 304: "max_match_rules_per_connection": max number of match rules for a single 305: connection 306: "max_replies_per_connection" : max number of pending method 307: replies per connection 308: (number of calls-in-progress) 309: "reply_timeout" : milliseconds (thousandths) 310: until a method call times out 311: .fi 312: 313: .PP 314: The max incoming/outgoing queue sizes allow a new message to be queued 315: if one byte remains below the max. So you can in fact exceed the max 316: by max_message_size. 317: 318: .PP 319: max_completed_connections divided by max_connections_per_user is the 320: number of users that can work together to denial-of-service all other users by using 321: up all connections on the systemwide bus. 322: 323: .PP 324: Limits are normally only of interest on the systemwide bus, not the user session 325: buses. 326: 327: .TP 328: .I "<policy>" 329: 330: .PP 331: The <policy> element defines a security policy to be applied to a particular 332: set of connections to the bus. A policy is made up of 333: <allow> and <deny> elements. Policies are normally used with the systemwide bus; 334: they are analogous to a firewall in that they allow expected traffic 335: and prevent unexpected traffic. 336: 337: .PP 338: The <policy> element has one of three attributes: 339: .nf 340: context="(default|mandatory)" 341: user="username or userid" 342: group="group name or gid" 343: .fi 344: 345: .PP 346: 347: Policies are applied to a connection as follows: 348: .nf 349: - all context="default" policies are applied 350: - all group="connection's user's group" policies are applied 351: in undefined order 352: - all user="connection's auth user" policies are applied 353: in undefined order 354: - all context="mandatory" policies are applied 355: .fi 356: 357: .PP 358: Policies applied later will override those applied earlier, 359: when the policies overlap. Multiple policies with the same 360: user/group/context are applied in the order they appear 361: in the config file. 362: 363: .TP 364: .I "<deny>" 365: .I "<allow>" 366: 367: .PP 368: A <deny> element appears below a <policy> element and prohibits some 369: action. The <allow> element makes an exception to previous <deny> 370: statements, and works just like <deny> but with the inverse meaning. 371: 372: .PP 373: The possible attributes of these elements are: 374: .nf 375: send_interface="interface_name" 376: send_member="method_or_signal_name" 377: send_error="error_name" 378: send_destination="name" 379: send_type="method_call" | "method_return" | "signal" | "error" 380: send_path="/path/name" 381: 382: receive_interface="interface_name" 383: receive_member="method_or_signal_name" 384: receive_error="error_name" 385: receive_sender="name" 386: receive_type="method_call" | "method_return" | "signal" | "error" 387: receive_path="/path/name" 388: 389: send_requested_reply="true" | "false" 390: receive_requested_reply="true" | "false" 391: 392: eavesdrop="true" | "false" 393: 394: own="name" 395: user="username" 396: group="groupname" 397: .fi 398: 399: .PP 400: Examples: 401: .nf 402: <deny send_interface="org.freedesktop.System" send_member="Reboot"/> 403: <deny receive_interface="org.freedesktop.System" receive_member="Reboot"/> 404: <deny own="org.freedesktop.System"/> 405: <deny send_destination="org.freedesktop.System"/> 406: <deny receive_sender="org.freedesktop.System"/> 407: <deny user="john"/> 408: <deny group="enemies"/> 409: .fi 410: 411: .PP 412: The <deny> element's attributes determine whether the deny "matches" a 413: particular action. If it matches, the action is denied (unless later 414: rules in the config file allow it). 415: 416: .PP 417: send_destination and receive_sender rules mean that messages may not be 418: sent to or received from the *owner* of the given name, not that 419: they may not be sent *to that name*. That is, if a connection 420: owns services A, B, C, and sending to A is denied, sending to B or C 421: will not work either. 422: 423: .PP 424: The other send_* and receive_* attributes are purely textual/by-value 425: matches against the given field in the message header. 426: 427: .PP 428: "Eavesdropping" occurs when an application receives a message that 429: was explicitly addressed to a name the application does not own. 430: Eavesdropping thus only applies to messages that are addressed to 431: services (i.e. it does not apply to signals). 432: 433: .PP 434: For <allow>, eavesdrop="true" indicates that the rule matches even 435: when eavesdropping. eavesdrop="false" is the default and means that 436: the rule only allows messages to go to their specified recipient. 437: For <deny>, eavesdrop="true" indicates that the rule matches 438: only when eavesdropping. eavesdrop="false" is the default for <deny> 439: also, but here it means that the rule applies always, even when 440: not eavesdropping. The eavesdrop attribute can only be combined with 441: receive rules (with receive_* attributes). 442: 443: 444: .PP 445: The [send|receive]_requested_reply attribute works similarly to the eavesdrop 446: attribute. It controls whether the <deny> or <allow> matches a reply 447: that is expected (corresponds to a previous method call message). 448: This attribute only makes sense for reply messages (errors and method 449: returns), and is ignored for other message types. 450: 451: .PP 452: For <allow>, [send|receive]_requested_reply="true" is the default and indicates that 453: only requested replies are allowed by the 454: rule. [send|receive]_requested_reply="false" means that the rule allows any reply 455: even if unexpected. 456: 457: .PP 458: For <deny>, [send|receive]_requested_reply="false" is the default but indicates that 459: the rule matches only when the reply was not 460: requested. [send|receive]_requested_reply="true" indicates that the rule applies 461: always, regardless of pending reply state. 462: 463: .PP 464: user and group denials mean that the given user or group may 465: not connect to the message bus. 466: 467: .PP 468: For "name", "username", "groupname", etc. 469: the character "*" can be substituted, meaning "any." Complex globs 470: like "foo.bar.*" aren't allowed for now because they'd be work to 471: implement and maybe encourage sloppy security anyway. 472: 473: .PP 474: It does not make sense to deny a user or group inside a <policy> 475: for a user or group; user/group denials can only be inside 476: context="default" or context="mandatory" policies. 477: 478: .PP 479: A single <deny> rule may specify combinations of attributes such as 480: send_destination and send_interface and send_type. In this case, the 481: denial applies only if both attributes match the message being denied. 482: e.g. <deny send_interface="foo.bar" send_destination="foo.blah"/> would 483: deny messages with the given interface AND the given bus name. 484: To get an OR effect you specify multiple <deny> rules. 485: 486: .PP 487: You can't include both send_ and receive_ attributes on the same 488: rule, since "whether the message can be sent" and "whether it can be 489: received" are evaluated separately. 490: 491: .PP 492: Be careful with send_interface/receive_interface, because the 493: interface field in messages is optional. 494: 495: .TP 496: .I "<selinux>" 497: 498: .PP 499: The <selinux> element contains settings related to Security Enhanced Linux. 500: More details below. 501: 502: .TP 503: .I "<associate>" 504: 505: .PP 506: An <associate> element appears below an <selinux> element and 507: creates a mapping. Right now only one kind of association is possible: 508: .nf 509: <associate own="org.freedesktop.Foobar" context="foo_t"/> 510: .fi 511: 512: .PP 513: This means that if a connection asks to own the name 514: "org.freedesktop.Foobar" then the source context will be the context 515: of the connection and the target context will be "foo_t" - see the 516: short discussion of SELinux below. 517: 518: .PP 519: Note, the context here is the target context when requesting a name, 520: NOT the context of the connection owning the name. 521: 522: .PP 523: There's currently no way to set a default for owning any name, if 524: we add this syntax it will look like: 525: .nf 526: <associate own="*" context="foo_t"/> 527: .fi 528: If you find a reason this is useful, let the developers know. 529: Right now the default will be the security context of the bus itself. 530: 531: .PP 532: If two <associate> elements specify the same name, the element 533: appearing later in the configuration file will be used. 534: 535: .SH SELinux 536: 537: .PP 538: See http://www.nsa.gov/selinux/ for full details on SELinux. Some useful excerpts: 539: 540: .IP "" 8 541: Every subject (process) and object (e.g. file, socket, IPC object, 542: etc) in the system is assigned a collection of security attributes, 543: known as a security context. A security context contains all of the 544: security attributes associated with a particular subject or object 545: that are relevant to the security policy. 546: 547: .IP "" 8 548: In order to better encapsulate security contexts and to provide 549: greater efficiency, the policy enforcement code of SELinux typically 550: handles security identifiers (SIDs) rather than security contexts. A 551: SID is an integer that is mapped by the security server to a security 552: context at runtime. 553: 554: .IP "" 8 555: When a security decision is required, the policy enforcement code 556: passes a pair of SIDs (typically the SID of a subject and the SID of 557: an object, but sometimes a pair of subject SIDs or a pair of object 558: SIDs), and an object security class to the security server. The object 559: security class indicates the kind of object, e.g. a process, a regular 560: file, a directory, a TCP socket, etc. 561: 562: .IP "" 8 563: Access decisions specify whether or not a permission is granted for a 564: given pair of SIDs and class. Each object class has a set of 565: associated permissions defined to control operations on objects with 566: that class. 567: 568: .PP 569: D-Bus performs SELinux security checks in two places. 570: 571: .PP 572: First, any time a message is routed from one connection to another 573: connection, the bus daemon will check permissions with the security context of 574: the first connection as source, security context of the second connection 575: as target, object class "dbus" and requested permission "send_msg". 576: 577: .PP 578: If a security context is not available for a connection 579: (impossible when using UNIX domain sockets), then the target 580: context used is the context of the bus daemon itself. 581: There is currently no way to change this default, because we're 582: assuming that only UNIX domain sockets will be used to 583: connect to the systemwide bus. If this changes, we'll 584: probably add a way to set the default connection context. 585: 586: .PP 587: Second, any time a connection asks to own a name, 588: the bus daemon will check permissions with the security 589: context of the connection as source, the security context specified 590: for the name in the config file as target, object 591: class "dbus" and requested permission "acquire_svc". 592: 593: .PP 594: The security context for a bus name is specified with the 595: <associate> element described earlier in this document. 596: If a name has no security context associated in the 597: configuration file, the security context of the bus daemon 598: itself will be used. 599: 600: .SH AUTHOR 601: See http://www.freedesktop.org/software/dbus/doc/AUTHORS 602: 603: .SH BUGS 604: Please send bug reports to the D-Bus mailing list or bug tracker, 605: see http://www.freedesktop.org/software/dbus/