1 <?xml version="1.0" standalone="no"?>
2 <!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
3 "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd"
9 <title>D-BUS Specification</title>
10 <releaseinfo>Version 0.11</releaseinfo>
11 <date>6 February 2005</date>
14 <firstname>Havoc</firstname>
15 <surname>Pennington</surname>
17 <orgname>Red Hat, Inc.</orgname>
19 <email>hp@pobox.com</email>
24 <firstname>Anders</firstname>
25 <surname>Carlsson</surname>
27 <orgname>CodeFactory AB</orgname>
29 <email>andersca@codefactory.se</email>
34 <firstname>Alexander</firstname>
35 <surname>Larsson</surname>
37 <orgname>Red Hat, Inc.</orgname>
39 <email>alexl@redhat.com</email>
46 <sect1 id="introduction">
47 <title>Introduction</title>
49 D-BUS is a system for low-latency, low-overhead, easy to use
50 interprocess communication (IPC). In more detail:
54 D-BUS is <emphasis>low-latency</emphasis> because it is designed
55 to avoid round trips and allow asynchronous operation, much like
61 D-BUS is <emphasis>low-overhead</emphasis> because it uses a
62 binary protocol, and does not have to convert to and from a text
63 format such as XML. Because D-BUS is intended for potentially
64 high-resolution same-machine IPC, not primarily for Internet IPC,
65 this is an interesting optimization.
70 D-BUS is <emphasis>easy to use</emphasis> because it works in terms
71 of <firstterm>messages</firstterm> rather than byte streams, and
72 automatically handles a lot of the hard IPC issues. Also, the D-BUS
73 library is designed to be wrapped in a way that lets developers use
74 their framework's existing object/type system, rather than learning
75 a new one specifically for IPC.
82 The base D-BUS protocol is a one-to-one (peer-to-peer or client-server)
83 protocol, specified in <xref linkend="message-protocol"/>. That is, it is
84 a system for one application to talk to a single other
85 application. However, the primary intended application of the protocol is the
86 D-BUS <firstterm>message bus</firstterm>, specified in <xref
87 linkend="message-bus"/>. The message bus is a special application that
88 accepts connections from multiple other applications, and forwards
93 Uses of D-BUS include notification of system changes (notification of when
94 a camera is plugged in to a computer, or a new version of some software
95 has been installed), or desktop interoperability, for example a file
96 monitoring service or a configuration service.
100 D-BUS is designed for two specific use cases:
104 A "system bus" for notifications from the system to user sessions,
105 and to allow the system to request input from user sessions.
110 A "session bus" used to implement desktop environments such as
115 D-BUS is not intended to be a generic IPC system for any possible
116 application, and intentionally omits many features found in other
117 IPC systems for this reason. D-BUS may turn out to be useful
118 in unanticipated applications, but future versions of this
119 spec and the reference implementation probably will not
120 incorporate features that interfere with the core use cases.
124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
126 document are to be interpreted as described in RFC 2119. However, the
127 document could use a serious audit to be sure it makes sense to do
128 so. Also, they are not capitalized.
133 <sect1 id="message-protocol">
134 <title>Message Protocol</title>
137 A <firstterm>message</firstterm> consists of a
138 <firstterm>header</firstterm> and a <firstterm>body</firstterm>. If you
139 think of a message as a package, the header is the address, and the body
140 contains the package contents. The message delivery system uses the header
141 information to figure out where to send the message and how to interpret
142 it; the recipient inteprets the body of the message.
146 The body of the message is made up of zero or more
147 <firstterm>arguments</firstterm>, which are typed values, such as an
148 integer or a byte array.
152 Both header and body use the same type system and format for
153 serializing data. Each type of value has a wire format.
154 Converting a value from some other representation into the wire
155 format is called <firstterm>marshaling</firstterm> and converting
156 it back from the wire format is <firstterm>unmarshaling</firstterm>.
159 <sect2 id="message-protocol-signatures">
160 <title>Type Signatures</title>
163 The D-BUS protocol does not include type tags in the marshaled data; a
164 block of marshaled values must have a known <firstterm>type
165 signature</firstterm>. The type signature is made up of <firstterm>type
166 codes</firstterm>. A type code is an ASCII character representing the
167 type of a value. Because ASCII characters are used, the type signature
168 will always form a valid ASCII string. A simple string compare
169 determines whether two type signatures are equivalent.
173 As a simple example, the type code for 32-bit integer (<literal>INT32</literal>) is
174 the ASCII character 'i'. So the signature for a block of values
175 containing a single <literal>INT32</literal> would be:
179 A block of values containing two <literal>INT32</literal> would have this signature:
186 All <firstterm>basic</firstterm> types work like
187 <literal>INT32</literal> in this example. To marshal and unmarshal
188 basic types, you simply read one value from the data
189 block corresponding to each type code in the signature.
190 In addition to basic types, there are four <firstterm>container</firstterm>
191 types: <literal>STRUCT</literal>, <literal>ARRAY</literal>, <literal>VARIANT</literal>,
192 and <literal>DICT_ENTRY</literal>.
196 <literal>STRUCT</literal> has a type code, ASCII character 'r', but this type
197 code does not appear in signatures. Instead, ASCII characters
198 '(' and ')' are used to mark the beginning and end of the struct.
199 So for example, a struct containing two integers would have this
204 Structs can be nested, so for example a struct containing
205 an integer and another struct:
209 The value block storing that struct would contain three integers; the
210 type signature allows you to distinguish "(i(ii))" from "((ii)i)" or
215 The <literal>STRUCT</literal> type code 'r' is not currently used in the D-BUS protocol,
216 but is useful in code that implements the protocol. This type code
217 is specified to allow such code to interoperate in non-protocol contexts.
221 <literal>ARRAY</literal> has ASCII character 'a' as type code. The array type code must be
222 followed by a <firstterm>single complete type</firstterm>. The single
223 complete type following the array is the type of each array element. So
224 the simple example is:
228 which is an array of 32-bit integers. But an array can be of any type,
229 such as this array-of-struct-with-two-int32-fields:
233 Or this array of array of integer:
240 The phrase <firstterm>single complete type</firstterm> deserves some
241 definition. A single complete type is a basic type code, a variant type code,
242 an array with its element type, or a struct with its fields.
243 So the following signatures are not single complete types:
253 And the following signatures contain multiple complete types:
263 Note however that a single complete type may <emphasis>contain</emphasis>
264 multiple other single complete types.
268 <literal>VARIANT</literal> has ASCII character 'v' as its type code. A marshaled value of
269 type <literal>VARIANT</literal> will have the signature of a single complete type as part
270 of the <emphasis>value</emphasis>. This signature will be followed by a
271 marshaled value of that type.
275 A <literal>DICT_ENTRY</literal> works exactly like a struct, but rather
276 than parentheses it uses curly braces, and it has more restrictions.
277 The restrictions are: it occurs only as an array element type; it has
278 exactly two single complete types inside the curly braces; the first
279 single complete type (the "key") must be a basic type rather than a
280 container type. Implementations must not accept dict entries outside of
281 arrays, must not accept dict entries with zero, one, or more than two
282 fields, and must not accept dict entries with non-basic-typed keys. A
283 dict entry is always a key-value pair.
287 The first field in the <literal>DICT_ENTRY</literal> is always the key.
288 A message is considered corrupt if the same key occurs twice in the same
289 array of <literal>DICT_ENTRY</literal>. However, for performance reasons
290 implementations are not required to reject dicts with duplicate keys.
294 In most languages, an array of dict entry would be represented as a
295 map, hash table, or dict object.
299 The following table summarizes the D-BUS types.
304 <entry>Conventional Name</entry>
306 <entry>Description</entry>
311 <entry><literal>INVALID</literal></entry>
312 <entry>0 (ASCII NUL)</entry>
313 <entry>Not a valid type code, used to terminate signatures</entry>
315 <entry><literal>BYTE</literal></entry>
316 <entry>121 (ASCII 'y')</entry>
317 <entry>8-bit unsigned integer</entry>
319 <entry><literal>BOOLEAN</literal></entry>
320 <entry>98 (ASCII 'b')</entry>
321 <entry>Boolean value, 0 is <literal>FALSE</literal> and 1 is <literal>TRUE</literal>. Everything else is invalid.</entry>
323 <entry><literal>INT16</literal></entry>
324 <entry>110 (ASCII 'n')</entry>
325 <entry>16-bit signed integer</entry>
327 <entry><literal>UINT16</literal></entry>
328 <entry>113 (ASCII 'q')</entry>
329 <entry>16-bit unsigned integer</entry>
331 <entry><literal>INT32</literal></entry>
332 <entry>105 (ASCII 'i')</entry>
333 <entry>32-bit signed integer</entry>
335 <entry><literal>UINT32</literal></entry>
336 <entry>117 (ASCII 'u')</entry>
337 <entry>32-bit unsigned integer</entry>
339 <entry><literal>INT64</literal></entry>
340 <entry>120 (ASCII 'x')</entry>
341 <entry>64-bit signed integer</entry>
343 <entry><literal>UINT64</literal></entry>
344 <entry>116 (ASCII 't')</entry>
345 <entry>64-bit unsigned integer</entry>
347 <entry><literal>DOUBLE</literal></entry>
348 <entry>100 (ASCII 'd')</entry>
349 <entry>IEEE 754 double</entry>
351 <entry><literal>STRING</literal></entry>
352 <entry>115 (ASCII 's')</entry>
353 <entry>UTF-8 string (<emphasis>must</emphasis> be valid UTF-8). Must be nul terminated.</entry>
355 <entry><literal>OBJECT_PATH</literal></entry>
356 <entry>111 (ASCII 'o')</entry>
357 <entry>Name of an object instance</entry>
359 <entry><literal>SIGNATURE</literal></entry>
360 <entry>103 (ASCII 'g')</entry>
361 <entry>A type signature</entry>
363 <entry><literal>ARRAY</literal></entry>
364 <entry>97 (ASCII 'a')</entry>
367 <entry><literal>STRUCT</literal></entry>
368 <entry>114 (ASCII 'r'), 40 (ASCII '('), 41 (ASCII ')')</entry>
369 <entry>Struct</entry>
371 <entry><literal>VARIANT</literal></entry>
372 <entry>118 (ASCII 'v') </entry>
373 <entry>Variant type (the type of the value is part of the value itself)</entry>
375 <entry><literal>DICT_ENTRY</literal></entry>
376 <entry>101 (ASCII 'e'), 123 (ASCII '{'), 125 (ASCII '}') </entry>
377 <entry>Entry in a dict or map (array of key-value pairs)</entry>
386 <sect2 id="message-protocol-marshaling">
387 <title>Marshaling (Wire Format)</title>
390 Given a type signature, a block of bytes can be converted into typed
391 values. This section describes the format of the block of bytes. Byte
392 order and alignment issues are handled uniformly for all D-BUS types.
396 A block of bytes has an associated byte order. The byte order
397 has to be discovered in some way; for D-BUS messages, the
398 byte order is part of the message header as described in
399 <xref linkend="message-protocol-messages"/>. For now, assume
400 that the byte order is known to be either little endian or big
405 Each value in a block of bytes is aligned "naturally," for example
406 4-byte values are aligned to a 4-byte boundary, and 8-byte values to an
407 8-byte boundary. To properly align a value, <firstterm>alignment
408 padding</firstterm> may be necessary. The alignment padding must always
409 be the minimum required padding to properly align the following value;
410 and it must always be made up of nul bytes. The alignment padding must
411 not be left uninitialized (it can't contain garbage), and more padding
412 than required must not be used.
416 Given all this, the types are marshaled on the wire as follows:
421 <entry>Conventional Name</entry>
422 <entry>Encoding</entry>
423 <entry>Alignment</entry>
428 <entry><literal>INVALID</literal></entry>
429 <entry>Not applicable; cannot be marshaled.</entry>
432 <entry><literal>BYTE</literal></entry>
433 <entry>A single 8-bit byte.</entry>
436 <entry><literal>BOOLEAN</literal></entry>
437 <entry>As for <literal>UINT32</literal>, but only 0 and 1 are valid values.</entry>
440 <entry><literal>INT16</literal></entry>
441 <entry>16-bit signed integer in the message's byte order.</entry>
444 <entry><literal>UINT16</literal></entry>
445 <entry>16-bit unsigned integer in the message's byte order.</entry>
448 <entry><literal>INT32</literal></entry>
449 <entry>32-bit signed integer in the message's byte order.</entry>
452 <entry><literal>UINT32</literal></entry>
453 <entry>32-bit unsigned integer in the message's byte order.</entry>
456 <entry><literal>INT64</literal></entry>
457 <entry>64-bit signed integer in the message's byte order.</entry>
460 <entry><literal>UINT64</literal></entry>
461 <entry>64-bit unsigned integer in the message's byte order.</entry>
464 <entry><literal>DOUBLE</literal></entry>
465 <entry>64-bit IEEE 754 double in the message's byte order.</entry>
468 <entry><literal>STRING</literal></entry>
469 <entry>A <literal>UINT32</literal> indicating the string's
470 length in bytes excluding its terminating nul, followed by
471 string data of the given length, followed by a terminating nul
478 <entry><literal>OBJECT_PATH</literal></entry>
479 <entry>Exactly the same as <literal>STRING</literal> except the
480 content must be a valid object path (see below).
486 <entry><literal>SIGNATURE</literal></entry>
487 <entry>The same as <literal>STRING</literal> except the length is a single
488 byte (thus signatures have a maximum length of 255)
489 and the content must be a valid signature (see below).
495 <entry><literal>ARRAY</literal></entry>
497 A <literal>UINT32</literal> giving the length of the array data in bytes, followed by
498 alignment padding to the alignment boundary of the array element type,
499 followed by each array element. The array length is from the
500 end of the alignment padding to the end of the last element,
501 i.e. it does not include the padding after the length,
502 or any padding after the last element.
503 Arrays have a maximum length defined to be 2 to the 26th power or
504 67108864. Implementations must not send or accept arrays exceeding this
511 <entry><literal>STRUCT</literal></entry>
513 A struct must start on an 8-byte boundary regardless of the
514 type of the struct fields. The struct value consists of each
515 field marshaled in sequence starting from that 8-byte
522 <entry><literal>VARIANT</literal></entry>
524 A variant type has a marshaled <literal>SIGNATURE</literal>
525 followed by a marshaled value with the type
526 given in the signature.
527 Unlike a message signature, the variant signature
528 can contain only a single complete type.
529 So "i" is OK, "ii" is not.
532 1 (alignment of the signature)
535 <entry><literal>DICT_ENTRY</literal></entry>
548 <sect3 id="message-protocol-marshaling-object-path">
549 <title>Valid Object Paths</title>
552 An object path is a name used to refer to an object instance.
553 Conceptually, each participant in a D-BUS message exchange may have
554 any number of object instances (think of C++ or Java objects) and each
555 such instance will have a path. Like a filesystem, the object
556 instances in an application form a hierarchical tree.
560 The following rules define a valid object path. Implementations must
561 not send or accept messages with invalid object paths.
565 The path may be of any length.
570 The path must begin with an ASCII '/' (integer 47) character,
571 and must consist of elements separated by slash characters.
576 Each element must only contain the ASCII characters
582 No element may be the empty string.
587 Multiple '/' characters cannot occur in sequence.
592 A trailing '/' character is not allowed unless the
593 path is the root path (a single '/' character).
602 <sect3 id="message-protocol-marshaling-signature">
603 <title>Valid Signatures</title>
605 An implementation must not send or accept invalid signatures.
606 Valid signatures will conform to the following rules:
610 The signature ends with a nul byte.
615 The signature is a list of single complete types.
616 Arrays must have element types, and structs must
617 have both open and close parentheses.
622 Only type codes and open and close parentheses are
623 allowed in the signature. The <literal>STRUCT</literal> type code
624 is not allowed in signatures, because parentheses
630 The maximum depth of container type nesting is 32 array type
631 codes and 32 open parentheses. This implies that the maximum
632 total depth of recursion is 64, for an "array of array of array
633 of ... struct of struct of struct of ..." where there are 32
639 The maximum length of a signature is 255.
644 Signatures must be nul-terminated.
653 <sect2 id="message-protocol-messages">
654 <title>Message Format</title>
657 A message consists of a header and a body. The header is a block of
658 values with a fixed signature and meaning. The body is a separate block
659 of values, with a signature specified in the header.
663 The length of the header must be a multiple of 8, allowing the body to
664 begin on an 8-byte boundary when storing the entire message in a single
665 buffer. If the header does not naturally end on an 8-byte boundary
666 up to 7 bytes of nul-initialized alignment padding must be added.
670 The message body need not end on an 8-byte boundary.
674 The maximum length of a message, including header, header alignment padding,
675 and body is 2 to the 27th power or 134217728. Implementations must not
676 send or accept messages exceeding this size.
680 The signature of the header is:
684 Written out more readably, this is:
686 BYTE, BYTE, BYTE, BYTE, UINT32, UINT32, ARRAY of STRUCT of (BYTE,VARIANT)
691 These values have the following meanings:
697 <entry>Description</entry>
702 <entry>1st <literal>BYTE</literal></entry>
703 <entry>Endianness flag; ASCII 'l' for little-endian
704 or ASCII 'B' for big-endian. Both header and body are
705 in this endianness.</entry>
708 <entry>2nd <literal>BYTE</literal></entry>
709 <entry><firstterm>Message type</firstterm>. Unknown types must be ignored.
710 Currently-defined types are described below.
714 <entry>3rd <literal>BYTE</literal></entry>
715 <entry>Bitwise OR of flags. Unknown flags
716 must be ignored. Currently-defined flags are described below.
720 <entry>4th <literal>BYTE</literal></entry>
721 <entry>Major protocol version of the sending application. If
722 the major protocol version of the receiving application does not
723 match, the applications will not be able to communicate and the
724 D-BUS connection must be disconnected. The major protocol
725 version for this version of the specification is 0.
726 FIXME this field is stupid and pointless to put in
731 <entry>1st <literal>UINT32</literal></entry>
732 <entry>Length in bytes of the message body, starting
733 from the end of the header. The header ends after
734 its alignment padding to an 8-boundary.
738 <entry>2nd <literal>UINT32</literal></entry>
739 <entry>The serial of this message, used as a cookie
740 by the sender to identify the reply corresponding
745 <entry><literal>ARRAY</literal> of <literal>STRUCT</literal> of (<literal>BYTE</literal>,<literal>VARIANT</literal>)</entry>
746 <entry>An array of zero or more <firstterm>header
747 fields</firstterm> where the byte is the field code, and the
748 variant is the field value. The message type determines
749 which fields are required.
757 <firstterm>Message types</firstterm> that can appear in the second byte
763 <entry>Conventional name</entry>
764 <entry>Decimal value</entry>
765 <entry>Description</entry>
770 <entry><literal>INVALID</literal></entry>
772 <entry>This is an invalid type.</entry>
775 <entry><literal>METHOD_CALL</literal></entry>
777 <entry>Method call.</entry>
780 <entry><literal>METHOD_RETURN</literal></entry>
782 <entry>Method reply with returned data.</entry>
785 <entry><literal>ERROR</literal></entry>
787 <entry>Error reply. If the first argument exists and is a
788 string, it is an error message.</entry>
791 <entry><literal>SIGNAL</literal></entry>
793 <entry>Signal emission.</entry>
800 Flags that can appear in the third byte of the header:
805 <entry>Conventional name</entry>
806 <entry>Hex value</entry>
807 <entry>Description</entry>
812 <entry><literal>NO_REPLY_EXPECTED</literal></entry>
814 <entry>This message does not expect method return replies or
815 error replies; the reply can be omitted as an
816 optimization. However, it is compliant with this specification
817 to return the reply despite this flag and the only harm
818 from doing so is extra network traffic.
822 <entry><literal>NO_AUTO_START</literal></entry>
824 <entry>The bus must not launch an owner
825 for the destination name in response to this message.
833 <sect3 id="message-protocol-header-fields">
834 <title>Header Fields</title>
837 The array at the end of the header contains <firstterm>header
838 fields</firstterm>, where each field is a 1-byte field code followed
839 by a field value. A header must contain the required header fields for
840 its message type, and zero or more of any optional header
841 fields. Future versions of this protocol specification may add new
842 fields. Implementations must ignore fields they do not
843 understand. Implementations must not invent their own header fields;
844 only changes to this specification may introduce new header fields.
848 Again, if an implementation sees a header field code that it does not
849 expect, it must ignore that field, as it will be part of a new
850 (but compatible) version of this specification. This also applies
851 to known header fields appearing in unexpected messages, for
852 example: if a signal has a reply serial it must be ignored
853 even though it has no meaning as of this version of the spec.
857 However, implementations must not send or accept known header fields
858 with the wrong type stored in the field value. So for example a
859 message with an <literal>INTERFACE</literal> field of type
860 <literal>UINT32</literal> would be considered corrupt.
864 Here are the currently-defined header fields:
869 <entry>Conventional Name</entry>
870 <entry>Decimal Code</entry>
872 <entry>Required In</entry>
873 <entry>Description</entry>
878 <entry><literal>INVALID</literal></entry>
881 <entry>not allowed</entry>
882 <entry>Not a valid field name (error if it appears in a message)</entry>
885 <entry><literal>PATH</literal></entry>
887 <entry><literal>OBJECT_PATH</literal></entry>
888 <entry><literal>METHOD_CALL</literal>, <literal>SIGNAL</literal></entry>
889 <entry>The object to send a call to,
890 or the object a signal is emitted from.
894 <entry><literal>INTERFACE</literal></entry>
896 <entry><literal>STRING</literal></entry>
897 <entry><literal>SIGNAL</literal></entry>
899 The interface to invoke a method call on, or
900 that a signal is emitted from. Optional for
901 method calls, required for signals.
905 <entry><literal>MEMBER</literal></entry>
907 <entry><literal>STRING</literal></entry>
908 <entry><literal>METHOD_CALL</literal>, <literal>SIGNAL</literal></entry>
909 <entry>The member, either the method name or signal name.</entry>
912 <entry><literal>ERROR_NAME</literal></entry>
914 <entry><literal>STRING</literal></entry>
915 <entry><literal>ERROR</literal></entry>
916 <entry>The name of the error that occurred, for errors</entry>
919 <entry><literal>REPLY_SERIAL</literal></entry>
921 <entry><literal>UINT32</literal></entry>
922 <entry><literal>ERROR</literal>, <literal>METHOD_RETURN</literal></entry>
923 <entry>The serial number of the message this message is a reply
924 to. (The serial number is the second <literal>UINT32</literal> in the header.)</entry>
927 <entry><literal>DESTINATION</literal></entry>
929 <entry><literal>STRING</literal></entry>
930 <entry>optional</entry>
931 <entry>The name of the connection this message is intended for.
932 Only used in combination with the message bus, see
933 <xref linkend="message-bus"/>.</entry>
936 <entry><literal>SENDER</literal></entry>
938 <entry><literal>STRING</literal></entry>
939 <entry>optional</entry>
940 <entry>Unique name of the sending connection.
941 The message bus fills in this field so it is reliable; the field is
942 only meaningful in combination with the message bus.</entry>
945 <entry><literal>SIGNATURE</literal></entry>
947 <entry><literal>SIGNATURE</literal></entry>
948 <entry>optional</entry>
949 <entry>The signature of the message body.
950 If omitted, it is assumed to be the
951 empty signature "" (i.e. the body must be 0-length).</entry>
960 <sect2 id="message-protocol-names">
961 <title>Valid Names</title>
963 The various names in D-BUS messages have some restrictions.
966 There is a <firstterm>maximum name length</firstterm>
967 of 255 which applies to bus names, interfaces, and members.
969 <sect3 id="message-protocol-names-interface">
970 <title>Interface names</title>
972 Interfaces have names with type <literal>STRING</literal>, meaning that
973 they must be valid UTF-8. However, there are also some
974 additional restrictions that apply to interface names
977 <listitem><para>They are composed of 1 or more elements separated by
978 a period ('.') character. All elements must contain at least
982 <listitem><para>Each element must only contain the ASCII characters
983 "[A-Z][a-z][0-9]_" and must not begin with a digit.
987 <listitem><para>They must contain at least one '.' (period)
988 character (and thus at least two elements).
991 <listitem><para>They must not begin with a '.' (period) character.</para></listitem>
992 <listitem><para>They must not exceed the maximum name length.</para></listitem>
996 <sect3 id="message-protocol-names-bus">
997 <title>Bus names</title>
999 Bus names have the same restrictions as interface names, with a
1000 special exception for unique connection names. A unique name's first
1001 element must start with a colon (':') character. After the colon, any
1002 characters in "[A-Z][a-z][0-9]_" may appear. Elements after
1003 the first must follow the usual rules, except that they may start with
1004 a digit. Bus names not starting with a colon have none of these
1005 exceptions and follow the same rules as interface names.
1008 <sect3 id="message-protocol-names-member">
1009 <title>Member names</title>
1011 Member (i.e. method or signal) names:
1013 <listitem><para>Must only contain the ASCII characters
1014 "[A-Z][a-z][0-9]_" and may not begin with a
1015 digit.</para></listitem>
1016 <listitem><para>Must not contain the '.' (period) character.</para></listitem>
1017 <listitem><para>Must not exceed the maximum name length.</para></listitem>
1018 <listitem><para>Must be at least 1 byte in length.</para></listitem>
1022 <sect3 id="message-protocol-names-error">
1023 <title>Error names</title>
1025 Error names have the same restrictions as interface names.
1030 <sect2 id="message-protocol-types">
1031 <title>Message Types</title>
1033 Each of the message types (<literal>METHOD_CALL</literal>, <literal>METHOD_RETURN</literal>, <literal>ERROR</literal>, and
1034 <literal>SIGNAL</literal>) has its own expected usage conventions and header fields.
1035 This section describes these conventions.
1037 <sect3 id="message-protocol-types-method">
1038 <title>Method Calls</title>
1040 Some messages invoke an operation on a remote object. These are
1041 called method call messages and have the type tag <literal>METHOD_CALL</literal>. Such
1042 messages map naturally to methods on objects in a typical program.
1045 A method call message is required to have a <literal>MEMBER</literal> header field
1046 indicating the name of the method. Optionally, the message has an
1047 <literal>INTERFACE</literal> field giving the interface the method is a part of. In the
1048 absence of an <literal>INTERFACE</literal> field, if two interfaces on the same object have
1049 a method with the same name, it is undefined which of the two methods
1050 will be invoked. Implementations may also choose to return an error in
1051 this ambiguous case. However, if a method name is unique
1052 implementations must not require an interface field.
1055 Method call messages also include a <literal>PATH</literal> field
1056 indicating the object to invoke the method on. If the call is passing
1057 through a message bus, the message will also have a
1058 <literal>DESTINATION</literal> field giving the name of the connection
1059 to receive the message.
1062 When an application handles a method call message, it is required to
1063 return a reply. The reply is identified by a <literal>REPLY_SERIAL</literal> header field
1064 indicating the serial number of the <literal>METHOD_CALL</literal> being replied to. The
1065 reply can have one of two types; either <literal>METHOD_RETURN</literal> or <literal>ERROR</literal>.
1068 If the reply has type <literal>METHOD_RETURN</literal>, the arguments to the reply message
1069 are the return value(s) or "out parameters" of the method call.
1070 If the reply has type <literal>ERROR</literal>, then an "exception" has been thrown,
1071 and the call fails; no return value will be provided. It makes
1072 no sense to send multiple replies to the same method call.
1075 Even if a method call has no return values, a <literal>METHOD_RETURN</literal>
1076 reply is required, so the caller will know the method
1077 was successfully processed.
1080 The <literal>METHOD_RETURN</literal> or <literal>ERROR</literal> reply message must have the <literal>REPLY_SERIAL</literal>
1084 If a <literal>METHOD_CALL</literal> message has the flag <literal>NO_REPLY_EXPECTED</literal>,
1085 then as an optimization the application receiving the method
1086 call may choose to omit the reply message (regardless of
1087 whether the reply would have been <literal>METHOD_RETURN</literal> or <literal>ERROR</literal>).
1088 However, it is also acceptable to ignore the <literal>NO_REPLY_EXPECTED</literal>
1089 flag and reply anyway.
1092 Unless a message has the flag <literal>NO_AUTO_START</literal>, if the
1093 destination name does not exist then a program to own the destination
1094 name will be started before the message is delivered. The message
1095 will be held until the new program is successfully started or has
1096 failed to start; in case of failure, an error will be returned. This
1097 flag is only relevant in the context of a message bus, it is ignored
1098 during one-to-one communication with no intermediate bus.
1100 <sect4 id="message-protocol-types-method-apis">
1101 <title>Mapping method calls to native APIs</title>
1103 APIs for D-BUS may map method calls to a method call in a specific
1104 programming language, such as C++, or may map a method call written
1105 in an IDL to a D-BUS message.
1108 In APIs of this nature, arguments to a method are often termed "in"
1109 (which implies sent in the <literal>METHOD_CALL</literal>), or "out" (which implies
1110 returned in the <literal>METHOD_RETURN</literal>). Some APIs such as CORBA also have
1111 "inout" arguments, which are both sent and received, i.e. the caller
1112 passes in a value which is modified. Mapped to D-BUS, an "inout"
1113 argument is equivalent to an "in" argument, followed by an "out"
1114 argument. You can't pass things "by reference" over the wire, so
1115 "inout" is purely an illusion of the in-process API.
1118 Given a method with zero or one return values, followed by zero or more
1119 arguments, where each argument may be "in", "out", or "inout", the
1120 caller constructs a message by appending each "in" or "inout" argument,
1121 in order. "out" arguments are not represented in the caller's message.
1124 The recipient constructs a reply by appending first the return value
1125 if any, then each "out" or "inout" argument, in order.
1126 "in" arguments are not represented in the reply message.
1129 Error replies are normally mapped to exceptions in languages that have
1133 In converting from native APIs to D-BUS, it is perhaps nice to
1134 map D-BUS naming conventions ("FooBar") to native conventions
1135 such as "fooBar" or "foo_bar" automatically. This is OK
1136 as long as you can say that the native API is one that
1137 was specifically written for D-BUS. It makes the most sense
1138 when writing object implementations that will be exported
1139 over the bus. Object proxies used to invoke remote D-BUS
1140 objects probably need the ability to call any D-BUS method,
1141 and thus a magic name mapping like this could be a problem.
1144 This specification doesn't require anything of native API bindings;
1145 the preceding is only a suggested convention for consistency
1151 <sect3 id="message-protocol-types-signal">
1152 <title>Signal Emission</title>
1154 Unlike method calls, signal emissions have no replies.
1155 A signal emission is simply a single message of type <literal>SIGNAL</literal>.
1156 It must have three header fields: <literal>PATH</literal> giving the object
1157 the signal was emitted from, plus <literal>INTERFACE</literal> and <literal>MEMBER</literal> giving
1158 the fully-qualified name of the signal.
1162 <sect3 id="message-protocol-types-errors">
1163 <title>Errors</title>
1165 Messages of type <literal>ERROR</literal> are most commonly replies
1166 to a <literal>METHOD_CALL</literal>, but may be returned in reply
1167 to any kind of message. The message bus for example
1168 will return an <literal>ERROR</literal> in reply to a signal emission if
1169 the bus does not have enough memory to send the signal.
1172 An <literal>ERROR</literal> may have any arguments, but if the first
1173 argument is a <literal>STRING</literal>, it must be an error message.
1174 The error message may be logged or shown to the user
1179 <sect3 id="message-protocol-types-notation">
1180 <title>Notation in this document</title>
1182 This document uses a simple pseudo-IDL to describe particular method
1183 calls and signals. Here is an example of a method call:
1185 org.freedesktop.DBus.StartServiceByName (in STRING name, in UINT32 flags,
1186 out UINT32 resultcode)
1188 This means <literal>INTERFACE</literal> = org.freedesktop.DBus, <literal>MEMBER</literal> = StartServiceByName,
1189 <literal>METHOD_CALL</literal> arguments are <literal>STRING</literal> and <literal>UINT32</literal>, <literal>METHOD_RETURN</literal> argument
1190 is <literal>UINT32</literal>. Remember that the <literal>MEMBER</literal> field can't contain any '.' (period)
1191 characters so it's known that the last part of the name in
1192 the "IDL" is the member name.
1195 In C++ that might end up looking like this:
1197 unsigned int org::freedesktop::DBus::StartServiceByName (const char *name,
1198 unsigned int flags);
1200 or equally valid, the return value could be done as an argument:
1202 void org::freedesktop::DBus::StartServiceByName (const char *name,
1204 unsigned int *resultcode);
1206 It's really up to the API designer how they want to make
1207 this look. You could design an API where the namespace wasn't used
1208 in C++, using STL or Qt, using varargs, or whatever you wanted.
1211 Signals are written as follows:
1213 org.freedesktop.DBus.NameLost (STRING name)
1215 Signals don't specify "in" vs. "out" because only
1216 a single direction is possible.
1219 It isn't especially encouraged to use this lame pseudo-IDL in actual
1220 API implementations; you might use the native notation for the
1221 language you're using, or you might use COM or CORBA IDL, for example.
1226 <sect2 id="message-protocol-handling-invalid">
1227 <title>Invalid Protocol and Spec Extensions</title>
1230 For security reasons, the D-BUS protocol should be strictly parsed and
1231 validated, with the exception of defined extension points. Any invalid
1232 protocol or spec violations should result in immediately dropping the
1233 connection without notice to the other end. Exceptions should be
1234 carefully considered, e.g. an exception may be warranted for a
1235 well-understood idiosyncracy of a widely-deployed implementation. In
1236 cases where the other end of a connection is 100% trusted and known to
1237 be friendly, skipping validation for performance reasons could also make
1238 sense in certain cases.
1242 Generally speaking violations of the "must" requirements in this spec
1243 should be considered possible attempts to exploit security, and violations
1244 of the "should" suggestions should be considered legitimate (though perhaps
1245 they should generate an error in some cases).
1249 The following extension points are built in to D-BUS on purpose and must
1250 not be treated as invalid protocol. The extension points are intended
1251 for use by future versions of this spec, they are not intended for third
1252 parties. At the moment, the only way a third party could extend D-BUS
1253 without breaking interoperability would be to introduce a way to negotiate new
1254 feature support as part of the auth protocol, using EXTENSION_-prefixed
1255 commands. There is not yet a standard way to negotiate features.
1259 In the authentication protocol (see <xref linkend="auth-protocol"/>) unknown
1260 commands result in an ERROR rather than a disconnect. This enables
1261 future extensions to the protocol. Commands starting with EXTENSION_ are
1262 reserved for third parties.
1267 The authentication protocol supports pluggable auth mechanisms.
1272 The address format (see <xref linkend="addresses"/>) supports new
1278 Messages with an unknown type (something other than
1279 <literal>METHOD_CALL</literal>, <literal>METHOD_RETURN</literal>,
1280 <literal>ERROR</literal>, <literal>SIGNAL</literal>) are ignored.
1281 Unknown-type messages must still be well-formed in the same way
1282 as the known messages, however. They still have the normal
1288 Header fields with an unknown or unexpected field code must be ignored,
1289 though again they must still be well-formed.
1294 New standard interfaces (with new methods and signals) can of course be added.
1304 <sect1 id="auth-protocol">
1305 <title>Authentication Protocol</title>
1307 Before the flow of messages begins, two applications must
1308 authenticate. A simple plain-text protocol is used for
1309 authentication; this protocol is a SASL profile, and maps fairly
1310 directly from the SASL specification. The message encoding is
1311 NOT used here, only plain text messages.
1314 In examples, "C:" and "S:" indicate lines sent by the client and
1315 server respectively.
1317 <sect2 id="auth-protocol-overview">
1318 <title>Protocol Overview</title>
1320 The protocol is a line-based protocol, where each line ends with
1321 \r\n. Each line begins with an all-caps ASCII command name containing
1322 only the character range [A-Z_], a space, then any arguments for the
1323 command, then the \r\n ending the line. The protocol is
1324 case-sensitive. All bytes must be in the ASCII character set.
1326 Commands from the client to the server are as follows:
1329 <listitem><para>AUTH [mechanism] [initial-response]</para></listitem>
1330 <listitem><para>CANCEL</para></listitem>
1331 <listitem><para>BEGIN</para></listitem>
1332 <listitem><para>DATA <data in hex encoding></para></listitem>
1333 <listitem><para>ERROR [human-readable error explanation]</para></listitem>
1336 From server to client are as follows:
1339 <listitem><para>REJECTED <space-separated list of mechanism names></para></listitem>
1340 <listitem><para>OK</para></listitem>
1341 <listitem><para>DATA <data in hex encoding></para></listitem>
1342 <listitem><para>ERROR</para></listitem>
1346 Unofficial extensions to the command set must begin with the letters
1347 "EXTENSION_", to avoid conflicts with future official commands.
1348 For example, "EXTENSION_COM_MYDOMAIN_DO_STUFF".
1351 <sect2 id="auth-nul-byte">
1352 <title>Special credentials-passing nul byte</title>
1354 Immediately after connecting to the server, the client must send a
1355 single nul byte. This byte may be accompanied by credentials
1356 information on some operating systems that use sendmsg() with
1357 SCM_CREDS or SCM_CREDENTIALS to pass credentials over UNIX domain
1358 sockets. However, the nul byte must be sent even on other kinds of
1359 socket, and even on operating systems that do not require a byte to be
1360 sent in order to transmit credentials. The text protocol described in
1361 this document begins after the single nul byte. If the first byte
1362 received from the client is not a nul byte, the server may disconnect
1366 A nul byte in any context other than the initial byte is an error;
1367 the protocol is ASCII-only.
1370 The credentials sent along with the nul byte may be used with the
1371 SASL mechanism EXTERNAL.
1374 <sect2 id="auth-command-auth">
1375 <title>AUTH command</title>
1377 If an AUTH command has no arguments, it is a request to list
1378 available mechanisms. The server must respond with a REJECTED
1379 command listing the mechanisms it understands, or with an error.
1382 If an AUTH command specifies a mechanism, and the server supports
1383 said mechanism, the server should begin exchanging SASL
1384 challenge-response data with the client using DATA commands.
1387 If the server does not support the mechanism given in the AUTH
1388 command, it must send either a REJECTED command listing the mechanisms
1389 it does support, or an error.
1392 If the [initial-response] argument is provided, it is intended for use
1393 with mechanisms that have no initial challenge (or an empty initial
1394 challenge), as if it were the argument to an initial DATA command. If
1395 the selected mechanism has an initial challenge and [initial-response]
1396 was provided, the server should reject authentication by sending
1400 If authentication succeeds after exchanging DATA commands,
1401 an OK command must be sent to the client.
1404 The first octet received by the client after the \r\n of the OK
1405 command must be the first octet of the authenticated/encrypted
1406 stream of D-BUS messages.
1409 The first octet received by the server after the \r\n of the BEGIN
1410 command from the client must be the first octet of the
1411 authenticated/encrypted stream of D-BUS messages.
1414 <sect2 id="auth-command-cancel">
1415 <title>CANCEL Command</title>
1417 At any time up to sending the BEGIN command, the client may send a
1418 CANCEL command. On receiving the CANCEL command, the server must
1419 send a REJECTED command and abort the current authentication
1423 <sect2 id="auth-command-data">
1424 <title>DATA Command</title>
1426 The DATA command may come from either client or server, and simply
1427 contains a hex-encoded block of data to be interpreted
1428 according to the SASL mechanism in use.
1431 Some SASL mechanisms support sending an "empty string";
1432 FIXME we need some way to do this.
1435 <sect2 id="auth-command-begin">
1436 <title>BEGIN Command</title>
1438 The BEGIN command acknowledges that the client has received an
1439 OK command from the server, and that the stream of messages
1443 The first octet received by the server after the \r\n of the BEGIN
1444 command from the client must be the first octet of the
1445 authenticated/encrypted stream of D-BUS messages.
1448 <sect2 id="auth-command-rejected">
1449 <title>REJECTED Command</title>
1451 The REJECTED command indicates that the current authentication
1452 exchange has failed, and further exchange of DATA is inappropriate.
1453 The client would normally try another mechanism, or try providing
1454 different responses to challenges.
1456 Optionally, the REJECTED command has a space-separated list of
1457 available auth mechanisms as arguments. If a server ever provides
1458 a list of supported mechanisms, it must provide the same list
1459 each time it sends a REJECTED message. Clients are free to
1460 ignore all lists received after the first.
1463 <sect2 id="auth-command-ok">
1464 <title>OK Command</title>
1466 The OK command indicates that the client has been authenticated,
1467 and that further communication will be a stream of D-BUS messages
1468 (optionally encrypted, as negotiated) rather than this protocol.
1471 The first octet received by the client after the \r\n of the OK
1472 command must be the first octet of the authenticated/encrypted
1473 stream of D-BUS messages.
1476 The client must respond to the OK command by sending a BEGIN
1477 command, followed by its stream of messages, or by disconnecting.
1478 The server must not accept additional commands using this protocol
1479 after the OK command has been sent.
1482 <sect2 id="auth-command-error">
1483 <title>ERROR Command</title>
1485 The ERROR command indicates that either server or client did not
1486 know a command, does not accept the given command in the current
1487 context, or did not understand the arguments to the command. This
1488 allows the protocol to be extended; a client or server can send a
1489 command present or permitted only in new protocol versions, and if
1490 an ERROR is received instead of an appropriate response, fall back
1491 to using some other technique.
1494 If an ERROR is sent, the server or client that sent the
1495 error must continue as if the command causing the ERROR had never been
1496 received. However, the the server or client receiving the error
1497 should try something other than whatever caused the error;
1498 if only canceling/rejecting the authentication.
1501 If the D-BUS protocol changes incompatibly at some future time,
1502 applications implementing the new protocol would probably be able to
1503 check for support of the new protocol by sending a new command and
1504 receiving an ERROR from applications that don't understand it. Thus the
1505 ERROR feature of the auth protocol is an escape hatch that lets us
1506 negotiate extensions or changes to the D-BUS protocol in the future.
1509 <sect2 id="auth-examples">
1510 <title>Authentication examples</title>
1514 <title>Example of successful magic cookie authentication</title>
1516 (MAGIC_COOKIE is a made up mechanism)
1518 C: AUTH MAGIC_COOKIE 3138363935333137393635383634
1524 <title>Example of finding out mechanisms then picking one</title>
1527 S: REJECTED KERBEROS_V4 SKEY
1528 C: AUTH SKEY 7ab83f32ee
1529 S: DATA 8799cabb2ea93e
1530 C: DATA 8ac876e8f68ee9809bfa876e6f9876g8fa8e76e98f
1536 <title>Example of client sends unknown command then falls back to regular auth</title>
1540 C: AUTH MAGIC_COOKIE 3736343435313230333039
1546 <title>Example of server doesn't support initial auth mechanism</title>
1548 C: AUTH MAGIC_COOKIE 3736343435313230333039
1549 S: REJECTED KERBEROS_V4 SKEY
1550 C: AUTH SKEY 7ab83f32ee
1551 S: DATA 8799cabb2ea93e
1552 C: DATA 8ac876e8f68ee9809bfa876e6f9876g8fa8e76e98f
1558 <title>Example of wrong password or the like followed by successful retry</title>
1560 C: AUTH MAGIC_COOKIE 3736343435313230333039
1561 S: REJECTED KERBEROS_V4 SKEY
1562 C: AUTH SKEY 7ab83f32ee
1563 S: DATA 8799cabb2ea93e
1564 C: DATA 8ac876e8f68ee9809bfa876e6f9876g8fa8e76e98f
1566 C: AUTH SKEY 7ab83f32ee
1567 S: DATA 8799cabb2ea93e
1568 C: DATA 8ac876e8f68ee9809bfa876e6f9876g8fa8e76e98f
1574 <title>Example of skey cancelled and restarted</title>
1576 C: AUTH MAGIC_COOKIE 3736343435313230333039
1577 S: REJECTED KERBEROS_V4 SKEY
1578 C: AUTH SKEY 7ab83f32ee
1579 S: DATA 8799cabb2ea93e
1582 C: AUTH SKEY 7ab83f32ee
1583 S: DATA 8799cabb2ea93e
1584 C: DATA 8ac876e8f68ee9809bfa876e6f9876g8fa8e76e98f
1591 <sect2 id="auth-states">
1592 <title>Authentication state diagrams</title>
1595 This section documents the auth protocol in terms of
1596 a state machine for the client and the server. This is
1597 probably the most robust way to implement the protocol.
1600 <sect3 id="auth-states-client">
1601 <title>Client states</title>
1604 To more precisely describe the interaction between the
1605 protocol state machine and the authentication mechanisms the
1606 following notation is used: MECH(CHALL) means that the
1607 server challenge CHALL was fed to the mechanism MECH, which
1613 CONTINUE(RESP) means continue the auth conversation
1614 and send RESP as the response to the server;
1620 OK(RESP) means that after sending RESP to the server
1621 the client side of the auth conversation is finished
1622 and the server should return "OK";
1628 ERROR means that CHALL was invalid and could not be
1634 Both RESP and CHALL may be empty.
1638 The Client starts by getting an initial response from the
1639 default mechanism and sends AUTH MECH RESP, or AUTH MECH if
1640 the mechanism did not provide an initial response. If the
1641 mechanism returns CONTINUE, the client starts in state
1642 <emphasis>WaitingForData</emphasis>, if the mechanism
1643 returns OK the client starts in state
1644 <emphasis>WaitingForOK</emphasis>.
1648 The client should keep track of available mechanisms and
1649 which it mechanisms it has already attempted. This list is
1650 used to decide which AUTH command to send. When the list is
1651 exhausted, the client should give up and close the
1656 <title><emphasis>WaitingForData</emphasis></title>
1664 MECH(CHALL) returns CONTINUE(RESP) → send
1666 <emphasis>WaitingForData</emphasis>
1670 MECH(CHALL) returns OK(RESP) → send DATA
1671 RESP, goto <emphasis>WaitingForOK</emphasis>
1675 MECH(CHALL) returns ERROR → send ERROR
1676 [msg], goto <emphasis>WaitingForData</emphasis>
1684 Receive REJECTED [mechs] →
1685 send AUTH [next mech], goto
1686 WaitingForData or <emphasis>WaitingForOK</emphasis>
1691 Receive ERROR → send
1693 <emphasis>WaitingForReject</emphasis>
1698 Receive OK → send
1699 BEGIN, terminate auth
1700 conversation, authenticated
1705 Receive anything else → send
1707 <emphasis>WaitingForData</emphasis>
1715 <title><emphasis>WaitingForOK</emphasis></title>
1720 Receive OK → send BEGIN, terminate auth
1721 conversation, <emphasis>authenticated</emphasis>
1726 Receive REJECT [mechs] → send AUTH [next mech],
1727 goto <emphasis>WaitingForData</emphasis> or
1728 <emphasis>WaitingForOK</emphasis>
1734 Receive DATA → send CANCEL, goto
1735 <emphasis>WaitingForReject</emphasis>
1741 Receive ERROR → send CANCEL, goto
1742 <emphasis>WaitingForReject</emphasis>
1748 Receive anything else → send ERROR, goto
1749 <emphasis>WaitingForOK</emphasis>
1757 <title><emphasis>WaitingForReject</emphasis></title>
1762 Receive REJECT [mechs] → send AUTH [next mech],
1763 goto <emphasis>WaitingForData</emphasis> or
1764 <emphasis>WaitingForOK</emphasis>
1770 Receive anything else → terminate auth
1771 conversation, disconnect
1780 <sect3 id="auth-states-server">
1781 <title>Server states</title>
1784 For the server MECH(RESP) means that the client response
1785 RESP was fed to the the mechanism MECH, which returns one of
1790 CONTINUE(CHALL) means continue the auth conversation and
1791 send CHALL as the challenge to the client;
1797 OK means that the client has been successfully
1804 REJECT means that the client failed to authenticate or
1805 there was an error in RESP.
1810 The server starts out in state
1811 <emphasis>WaitingForAuth</emphasis>. If the client is
1812 rejected too many times the server must disconnect the
1817 <title><emphasis>WaitingForAuth</emphasis></title>
1823 Receive AUTH → send REJECTED [mechs], goto
1824 <emphasis>WaitingForAuth</emphasis>
1830 Receive AUTH MECH RESP
1834 MECH not valid mechanism → send REJECTED
1836 <emphasis>WaitingForAuth</emphasis>
1840 MECH(RESP) returns CONTINUE(CHALL) → send
1842 <emphasis>WaitingForData</emphasis>
1846 MECH(RESP) returns OK → send OK, goto
1847 <emphasis>WaitingForBegin</emphasis>
1851 MECH(RESP) returns REJECT → send REJECTED
1853 <emphasis>WaitingForAuth</emphasis>
1861 Receive BEGIN → terminate
1862 auth conversation, disconnect
1868 Receive ERROR → send REJECTED [mechs], goto
1869 <emphasis>WaitingForAuth</emphasis>
1875 Receive anything else → send
1877 <emphasis>WaitingForAuth</emphasis>
1886 <title><emphasis>WaitingForData</emphasis></title>
1894 MECH(RESP) returns CONTINUE(CHALL) → send
1896 <emphasis>WaitingForData</emphasis>
1900 MECH(RESP) returns OK → send OK, goto
1901 <emphasis>WaitingForBegin</emphasis>
1905 MECH(RESP) returns REJECT → send REJECTED
1907 <emphasis>WaitingForAuth</emphasis>
1915 Receive BEGIN → terminate auth conversation,
1922 Receive CANCEL → send REJECTED [mechs], goto
1923 <emphasis>WaitingForAuth</emphasis>
1929 Receive ERROR → send REJECTED [mechs], goto
1930 <emphasis>WaitingForAuth</emphasis>
1936 Receive anything else → send ERROR, goto
1937 <emphasis>WaitingForData</emphasis>
1945 <title><emphasis>WaitingForBegin</emphasis></title>
1950 Receive BEGIN → terminate auth conversation,
1951 client authenticated
1957 Receive CANCEL → send REJECTED [mechs], goto
1958 <emphasis>WaitingForAuth</emphasis>
1964 Receive ERROR → send REJECTED [mechs], goto
1965 <emphasis>WaitingForAuth</emphasis>
1971 Receive anything else → send ERROR, goto
1972 <emphasis>WaitingForBegin</emphasis>
1982 <sect2 id="auth-mechanisms">
1983 <title>Authentication mechanisms</title>
1985 This section describes some new authentication mechanisms.
1986 D-BUS also allows any standard SASL mechanism of course.
1988 <sect3 id="auth-mechanisms-sha">
1989 <title>DBUS_COOKIE_SHA1</title>
1991 The DBUS_COOKIE_SHA1 mechanism is designed to establish that a client
1992 has the ability to read a private file owned by the user being
1993 authenticated. If the client can prove that it has access to a secret
1994 cookie stored in this file, then the client is authenticated.
1995 Thus the security of DBUS_COOKIE_SHA1 depends on a secure home
1999 Authentication proceeds as follows:
2003 The client sends the username it would like to authenticate
2009 The server sends the name of its "cookie context" (see below); a
2010 space character; the integer ID of the secret cookie the client
2011 must demonstrate knowledge of; a space character; then a
2012 hex-encoded randomly-generated challenge string.
2017 The client locates the cookie, and generates its own hex-encoded
2018 randomly-generated challenge string. The client then
2019 concatentates the server's hex-encoded challenge, a ":"
2020 character, its own hex-encoded challenge, another ":" character,
2021 and the hex-encoded cookie. It computes the SHA-1 hash of this
2022 composite string. It sends back to the server the client's
2023 hex-encoded challenge string, a space character, and the SHA-1
2029 The server generates the same concatenated string used by the
2030 client and computes its SHA-1 hash. It compares the hash with
2031 the hash received from the client; if the two hashes match, the
2032 client is authenticated.
2038 Each server has a "cookie context," which is a name that identifies a
2039 set of cookies that apply to that server. A sample context might be
2040 "org_freedesktop_session_bus". Context names must be valid ASCII,
2041 nonzero length, and may not contain the characters slash ("/"),
2042 backslash ("\"), space (" "), newline ("\n"), carriage return ("\r"),
2043 tab ("\t"), or period ("."). There is a default context,
2044 "org_freedesktop_general" that's used by servers that do not specify
2048 Cookies are stored in a user's home directory, in the directory
2049 <filename>~/.dbus-keyrings/</filename>. This directory must
2050 not be readable or writable by other users. If it is,
2051 clients and servers must ignore it. The directory
2052 contains cookie files named after the cookie context.
2055 A cookie file contains one cookie per line. Each line
2056 has three space-separated fields:
2060 The cookie ID number, which must be a non-negative integer and
2061 may not be used twice in the same file.
2066 The cookie's creation time, in UNIX seconds-since-the-epoch
2072 The cookie itself, a hex-encoded random block of bytes. The cookie
2073 may be of any length, though obviously security increases
2074 as the length increases.
2080 Only server processes modify the cookie file.
2081 They must do so with this procedure:
2085 Create a lockfile name by appending ".lock" to the name of the
2086 cookie file. The server should attempt to create this file
2087 using <literal>O_CREAT | O_EXCL</literal>. If file creation
2088 fails, the lock fails. Servers should retry for a reasonable
2089 period of time, then they may choose to delete an existing lock
2090 to keep users from having to manually delete a stale
2091 lock. <footnote><para>Lockfiles are used instead of real file
2092 locking <literal>fcntl()</literal> because real locking
2093 implementations are still flaky on network
2094 filesystems.</para></footnote>
2099 Once the lockfile has been created, the server loads the cookie
2100 file. It should then delete any cookies that are old (the
2101 timeout can be fairly short), or more than a reasonable
2102 time in the future (so that cookies never accidentally
2103 become permanent, if the clock was set far into the future
2104 at some point). If no recent keys remain, the
2105 server may generate a new key.
2110 The pruned and possibly added-to cookie file
2111 must be resaved atomically (using a temporary
2112 file which is rename()'d).
2117 The lock must be dropped by deleting the lockfile.
2123 Clients need not lock the file in order to load it,
2124 because servers are required to save the file atomically.
2129 <sect1 id="addresses">
2130 <title>Server Addresses</title>
2132 Server addresses consist of a transport name followed by a colon, and
2133 then an optional, comma-separated list of keys and values in the form key=value.
2134 [FIXME how do you escape colon, comma, and semicolon in the values of the key=value pairs?]
2138 <programlisting>unix:path=/tmp/dbus-test</programlisting>
2139 Which is the address to a unix socket with the path /tmp/dbus-test.
2142 [FIXME clarify if attempting to connect to each is a requirement
2143 or just a suggestion]
2144 When connecting to a server, multiple server addresses can be
2145 separated by a semi-colon. The library will then try to connect
2146 to the first address and if that fails, it'll try to connect to
2147 the next one specified, and so forth. For example
2148 <programlisting>unix:path=/tmp/dbus-test;unix:path=/tmp/dbus-test2</programlisting>
2151 [FIXME we need to specify in detail each transport and its possible arguments]
2152 Current transports include: unix domain sockets (including
2153 abstract namespace on linux), TCP/IP, and a debug/testing transport using
2154 in-process pipes. Future possible transports include one that
2155 tunnels over X11 protocol.
2159 <sect1 id="naming-conventions">
2160 <title>Naming Conventions</title>
2163 D-BUS namespaces are all lowercase and correspond to reversed domain
2164 names, as with Java. e.g. "org.freedesktop"
2167 Interface, signal, method, and property names are "WindowsStyleCaps", note
2168 that the first letter is capitalized, unlike Java.
2171 Object paths are normally all lowercase with underscores used rather than
2176 <sect1 id="standard-interfaces">
2177 <title>Standard Interfaces</title>
2179 See <xref linkend="message-protocol-types-notation"/> for details on
2180 the notation used in this section. There are some standard interfaces
2181 that may be useful across various D-BUS applications.
2183 <sect2 id="standard-interfaces-peer">
2184 <title><literal>org.freedesktop.Peer</literal></title>
2186 The <literal>org.freedesktop.Peer</literal> interface
2189 org.freedesktop.Peer.Ping ()
2193 On receipt of the <literal>METHOD_CALL</literal> message
2194 <literal>org.freedesktop.Peer.Ping</literal>, an application should do
2195 nothing other than reply with a <literal>METHOD_RETURN</literal> as
2196 usual. It does not matter which object path a ping is sent to. The
2197 reference implementation should simply handle this method on behalf of
2198 all objects, though it doesn't yet. (The point is, you're really pinging
2199 the peer process, not a specific object.)
2203 <sect2 id="standard-interfaces-introspectable">
2204 <title><literal>org.freedesktop.Introspectable</literal></title>
2206 This interface has one method:
2208 org.freedesktop.Introspectable.Introspect (out STRING xml_data)
2212 Objects instances may implement
2213 <literal>Introspect</literal> which returns an XML description of
2214 the object, including its interfaces (with signals and methods), objects
2215 below it in the object path tree, and its properties.
2218 <xref linkend="introspection-format"/> describes the format of this XML string.
2221 <sect2 id="standard-interfaces-properties">
2222 <title><literal>org.freedesktop.Properties</literal></title>
2224 Many native APIs will have a concept of object <firstterm>properties</firstterm>
2225 or <firstterm>attributes</firstterm>. These can be exposed via the
2226 <literal>org.freedesktop.Properties</literal> interface.
2230 org.freedesktop.Properties.Get (in STRING interface_name,
2231 in STRING property_name,
2233 org.freedesktop.Properties.Set (in STRING interface_name,
2234 in STRING property_name,
2239 The available properties and whether they are writable can be determined
2240 by calling <literal>org.freedesktop.Introspectable.Introspect</literal>,
2241 see <xref linkend="standard-interfaces-introspectable"/>.
2244 An empty string may be provided for the interface name; in this case,
2245 if there are multiple properties on an object with the same name,
2246 the results are undefined (picking one by according to an arbitrary
2247 deterministic rule, or returning an error, are the reasonable
2253 <sect1 id="introspection-format">
2254 <title>Introspection Data Format</title>
2256 As described in <xref linkend="standard-interfaces-introspectable"/>,
2257 objects may be introspected at runtime, returning an XML string
2258 that describes the object. The same XML format may be used in
2259 other contexts as well, for example as an "IDL" for generating
2260 static language bindings.
2263 Here is an example of introspection data:
2265 <!DOCTYPE node PUBLIC "-//freedesktop//DTD D-BUS Object Introspection 1.0//EN"
2266 "http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd">
2267 <node name="/org/freedesktop/sample_object">
2268 <interface name="org.freedesktop.SampleInterface">
2269 <method name="Frobate">
2270 <arg name="foo" type="int32" direction="in"/>
2271 <arg name="bar" type="string" direction="out"/>
2273 <signal name="Changed">
2274 <arg name="new_value" type="boolean"/>
2276 <property name="Bar" type="byte" access="readwrite"/>
2278 <node name="child_of_sample_object"/>
2279 <node name="another_child_of_sample_object"/>
2284 A more formal DTD and spec needs writing, but here are some quick notes.
2288 Only the root <node> element can omit the node name, as it's
2289 known to be the object that was introspected. If the root
2290 <node> does have a name attribute, it must be an absolute
2291 object path. If child <node> have object paths, they must be
2297 If a child <node> has any sub-elements, then they
2298 must represent a complete introspection of the child.
2299 If a child <node> is empty, then it may or may
2300 not have sub-elements; the child must be introspected
2301 in order to find out. The intent is that if an object
2302 knows that its children are "fast" to introspect
2303 it can go ahead and return their information, but
2304 otherwise it can omit it.
2309 The direction element on <arg> may be omitted,
2310 in which case it defaults to "in" for method calls
2311 and "out" for signals. Signals only allow "out"
2312 so while direction may be specified, it's pointless.
2317 The possible directions are "in" and "out",
2318 unlike CORBA there is no "inout"
2323 The possible property access flags are
2324 "readwrite", "read", and "write"
2329 The current type="uint32" stuff is totally broken,
2330 instead we have to do full signatures.
2331 However, then this format will suck for human readability.
2332 So, some thinking to do here.
2337 Multiple interfaces can of course be listed for
2343 The method, interface, property, and signal elements may have
2344 an attribute deprecated="yes|no". If the attribute is not
2345 present, the default value for an interface is "no", and
2346 the default value for methods, properties, and signals is
2347 the deprecation status of the interface.
2355 <sect1 id="message-bus">
2356 <title>Message Bus Specification</title>
2357 <sect2 id="message-bus-overview">
2358 <title>Message Bus Overview</title>
2360 The message bus accepts connections from one or more applications.
2361 Once connected, applications can exchange messages with other
2362 applications that are also connected to the bus.
2365 In order to route messages among connections, the message bus keeps a
2366 mapping from names to connections. Each connection has one
2367 unique-for-the-lifetime-of-the-bus name automatically assigned.
2368 Applications may request additional names for a connection. Additional
2369 names are usually "well-known names" such as
2370 "org.freedesktop.TextEditor". When a name is bound to a connection,
2371 that connection is said to <firstterm>own</firstterm> the name.
2374 The bus itself owns a special name, <literal>org.freedesktop.DBus</literal>.
2375 This name routes messages to the bus, allowing applications to make
2376 administrative requests. For example, applications can ask the bus
2377 to assign a name to a connection.
2380 Each name may have <firstterm>queued owners</firstterm>. When an
2381 application requests a name for a connection and the name is already in
2382 use, the bus will optionally add the connection to a queue waiting for
2383 the name. If the current owner of the name disconnects or releases
2384 the name, the next connection in the queue will become the new owner.
2388 This feature causes the right thing to happen if you start two text
2389 editors for example; the first one may request "org.freedesktop.TextEditor",
2390 and the second will be queued as a possible owner of that name. When
2391 the first exits, the second will take over.
2395 Messages may have a <literal>DESTINATION</literal> field (see <xref
2396 linkend="message-protocol-header-fields"/>). If the
2397 <literal>DESTINATION</literal> field is present, it specifies a message
2398 recipient by name. Method calls and replies normally specify this field.
2402 Signals normally do not specify a destination; they are sent to all
2403 applications with <firstterm>message matching rules</firstterm> that
2408 When the message bus receives a method call, if the
2409 <literal>DESTINATION</literal> field is absent, the call is taken to be
2410 a standard one-to-one message and interpreted by the message bus
2411 itself. For example, sending an
2412 <literal>org.freedesktop.Peer.Ping</literal> message with no
2413 <literal>DESTINATION</literal> will cause the message bus itself to
2414 reply to the ping immediately; the message bus will not make this
2415 message visible to other applications.
2419 Continuing the <literal>org.freedesktop.Peer.Ping</literal> example, if
2420 the ping message were sent with a <literal>DESTINATION</literal> name of
2421 <literal>com.yoyodyne.Screensaver</literal>, then the ping would be
2422 forwarded, and the Yoyodyne Corporation screensaver application would be
2423 expected to reply to the ping.
2427 <sect2 id="message-bus-names">
2428 <title>Message Bus Names</title>
2430 Each connection has at least one name, assigned at connection time and
2431 returned in response to the
2432 <literal>org.freedesktop.DBus.Hello</literal> method call. This
2433 automatically-assigned name is called the connection's <firstterm>unique
2434 name</firstterm>. Unique names are never reused for two different
2435 connections to the same bus.
2438 Ownership of a unique name is a prerequisite for interaction with
2439 the message bus. It logically follows that the unique name is always
2440 the first name that an application comes to own, and the last
2441 one that it loses ownership of.
2444 Unique connection names must begin with the character ':' (ASCII colon
2445 character); bus names that are not unique names must not begin
2446 with this character. (The bus must reject any attempt by an application
2447 to manually request a name beginning with ':'.) This restriction
2448 categorically prevents "spoofing"; messages sent to a unique name
2449 will always go to the expected connection.
2452 When a connection is closed, all the names that it owns are deleted (or
2453 transferred to the next connection in the queue if any).
2456 A connection can request additional names to be associated with it using
2457 the <literal>org.freedesktop.DBus.RequestName</literal> message. <xref
2458 linkend="message-protocol-names-bus"/> describes the format of a valid
2462 <sect3 id="bus-messages-request-name">
2463 <title><literal>org.freedesktop.DBus.RequestName</literal></title>
2467 UINT32 RequestName (in STRING name, in UINT32 flags)
2474 <entry>Argument</entry>
2476 <entry>Description</entry>
2482 <entry>STRING</entry>
2483 <entry>Name to request</entry>
2487 <entry>UINT32</entry>
2488 <entry>Flags</entry>
2498 <entry>Argument</entry>
2500 <entry>Description</entry>
2506 <entry>UINT32</entry>
2507 <entry>Return value</entry>
2514 This method call should be sent to
2515 <literal>org.freedesktop.DBus</literal> and asks the message bus to
2516 assign the given name to the method caller. The flags argument
2517 contains any of the following values logically ORed together:
2523 <entry>Conventional Name</entry>
2524 <entry>Value</entry>
2525 <entry>Description</entry>
2530 <entry>DBUS_NAME_FLAG_PROHIBIT_REPLACEMENT</entry>
2533 If the application succeeds in becoming the owner of the specified name,
2534 then ownership of the name can't be transferred until the application
2535 disconnects. If this flag is not set, then any application trying to become
2536 the owner of the name will succeed and the previous owner will be
2537 sent a <literal>org.freedesktop.DBus.NameLost</literal> signal.
2541 <entry>DBUS_NAME_FLAG_REPLACE_EXISTING</entry>
2544 Try to replace the current owner if there is one. If this
2545 flag is not set the application will only become the owner of
2546 the name if there is no current owner.
2553 The return code can be one of the following values:
2559 <entry>Conventional Name</entry>
2560 <entry>Value</entry>
2561 <entry>Description</entry>
2566 <entry>DBUS_REQUEST_NAME_REPLY_PRIMARY_OWNER</entry>
2567 <entry>1</entry> <entry>The caller is now the primary owner of
2568 the name, replacing any previous owner. Either the name had no
2569 owner before, or the caller specified
2570 DBUS_NAME_FLAG_REPLACE_EXISTING and the current owner did not
2571 specify DBUS_NAME_FLAG_PROHIBIT_REPLACEMENT.</entry>
2574 <entry>DBUS_REQUEST_NAME_REPLY_IN_QUEUE</entry>
2576 <entry>The name already had an owner, DBUS_NAME_FLAG_REPLACE_EXISTING was not specified, and the current owner specified DBUS_NAME_FLAG_PROHIBIT_REPLACEMENT.</entry>
2579 <entry>DBUS_REQUEST_NAME_REPLY_EXISTS</entry>
2581 <entry>The name already has an owner, and DBUS_NAME_FLAG_REPLACE_EXISTING was not specified.</entry>
2584 <entry>DBUS_REQUEST_NAME_REPLY_ALREADY_OWNER</entry>
2586 <entry>The application trying to request ownership of a name is already the owner of it.</entry>
2595 <sect2 id="message-bus-routing">
2596 <title>Message Bus Message Routing</title>
2601 <sect2 id="message-bus-starting-services">
2602 <title>Message Bus Starting Services</title>
2604 The message bus can start applications on behalf of other applications.
2605 In CORBA terms, this would be called <firstterm>activation</firstterm>.
2606 An application that can be started in this way is called a
2607 <firstterm>service</firstterm>.
2610 With D-BUS, starting a service is normally done by name. That is,
2611 applications ask the message bus to start some program that will own a
2612 well-known name, such as <literal>org.freedesktop.TextEditor</literal>.
2613 This implies a contract documented along with the name
2614 <literal>org.freedesktop.TextEditor</literal> for which objects
2615 the owner of that name will provide, and what interfaces those
2619 To find an executable corresponding to a particular name, the bus daemon
2620 looks for <firstterm>service description files</firstterm>. Service
2621 description files define a mapping from names to executables. Different
2622 kinds of message bus will look for these files in different places, see
2623 <xref linkend="message-bus-types"/>.
2626 [FIXME the file format should be much better specified than "similar to
2627 .desktop entries" esp. since desktop entries are already
2628 badly-specified. ;-)] Service description files have the ".service" file
2629 extension. The message bus will only load service description files
2630 ending with .service; all other files will be ignored. The file format
2631 is similar to that of <ulink
2632 url="http://www.freedesktop.org/standards/desktop-entry-spec/desktop-entry-spec.html">desktop
2633 entries</ulink>. All service description files must be in UTF-8
2634 encoding. To ensure that there will be no name collisions, service files
2635 must be namespaced using the same mechanism as messages and service
2639 <title>Example service description file</title>
2641 # Sample service description file
2643 Names=org.freedesktop.ConfigurationDatabase;org.gnome.GConf;
2644 Exec=/usr/libexec/gconfd-2
2649 When an application asks to start a service by name, the bus daemon tries to
2650 find a service that will own that name. It then tries to spawn the
2651 executable associated with it. If this fails, it will report an
2652 error. [FIXME what happens if two .service files offer the same service;
2653 what kind of error is reported, should we have a way for the client to
2657 The executable launched will have the environment variable
2658 <literal>DBUS_STARTER_ADDRESS</literal> set to the address of the
2659 message bus so it can connect and request the appropriate names.
2662 The executable being launched may want to know whether the message bus
2663 starting it is one of the well-known message buses (see <xref
2664 linkend="message-bus-types"/>). To facilitate this, the bus must also set
2665 the <literal>DBUS_STARTER_BUS_TYPE</literal> environment variable if it is one
2666 of the well-known buses. The currently-defined values for this variable
2667 are <literal>system</literal> for the systemwide message bus,
2668 and <literal>session</literal> for the per-login-session message
2669 bus. The new executable must still connect to the address given
2670 in <literal>DBUS_STARTER_ADDRESS</literal>, but may assume that the
2671 resulting connection is to the well-known bus.
2674 [FIXME there should be a timeout somewhere, either specified
2675 in the .service file, by the client, or just a global value
2676 and if the client being activated fails to connect within that
2677 timeout, an error should be sent back.]
2681 <sect2 id="message-bus-types">
2682 <title>Well-known Message Bus Instances</title>
2684 Two standard message bus instances are defined here, along with how
2685 to locate them and where their service files live.
2687 <sect3 id="message-bus-types-login">
2688 <title>Login session message bus</title>
2690 Each time a user logs in, a <firstterm>login session message
2691 bus</firstterm> may be started. All applications in the user's login
2692 session may interact with one another using this message bus.
2695 The address of the login session message bus is given
2696 in the <literal>DBUS_SESSION_BUS_ADDRESS</literal> environment
2697 variable. If that variable is not set, applications may
2698 also try to read the address from the X Window System root
2699 window property <literal>_DBUS_SESSION_BUS_ADDRESS</literal>.
2700 The root window property must have type <literal>STRING</literal>.
2701 The environment variable should have precedence over the
2702 root window property.
2705 [FIXME specify location of .service files, probably using
2706 DESKTOP_DIRS etc. from basedir specification, though login session
2707 bus is not really desktop-specific]
2710 <sect3 id="message-bus-types-system">
2711 <title>System message bus</title>
2713 A computer may have a <firstterm>system message bus</firstterm>,
2714 accessible to all applications on the system. This message bus may be
2715 used to broadcast system events, such as adding new hardware devices,
2716 changes in the printer queue, and so forth.
2719 The address of the system message bus is given
2720 in the <literal>DBUS_SYSTEM_BUS_ADDRESS</literal> environment
2721 variable. If that variable is not set, applications should try
2722 to connect to the well-known address
2723 <literal>unix:path=/var/run/dbus/system_bus_socket</literal>.
2726 The D-BUS reference implementation actually honors the
2727 <literal>$(localstatedir)</literal> configure option
2728 for this address, on both client and server side.
2733 [FIXME specify location of system bus .service files]
2738 <sect2 id="message-bus-messages">
2739 <title>Message Bus Messages</title>
2741 The special message bus name <literal>org.freedesktop.DBus</literal>
2742 responds to a number of additional messages.
2745 <sect3 id="bus-messages-hello">
2746 <title><literal>org.freedesktop.DBus.Hello</literal></title>
2757 <entry>Argument</entry>
2759 <entry>Description</entry>
2765 <entry>STRING</entry>
2766 <entry>Unique name assigned to the connection</entry>
2773 Before an application is able to send messages to other applications
2774 it must send the <literal>org.freedesktop.DBus.Hello</literal> message
2775 to the message bus to obtain a unique name. If an application without
2776 a unique name tries to send a message to another application, or a
2777 message to the message bus itself that isn't the
2778 <literal>org.freedesktop.DBus.Hello</literal> message, it will be
2779 disconnected from the bus.
2782 There is no corresponding "disconnect" request; if a client wishes to
2783 disconnect from the bus, it simply closes the socket (or other
2784 communication channel).
2787 <sect3 id="bus-messages-list-names">
2788 <title><literal>org.freedesktop.DBus.ListNames</literal></title>
2792 ARRAY of STRING ListNames ()
2799 <entry>Argument</entry>
2801 <entry>Description</entry>
2807 <entry>ARRAY of STRING</entry>
2808 <entry>Array of strings where each string is a bus name</entry>
2815 Returns a list of all currently-owned names on the bus.
2818 <sect3 id="bus-messages-name-exists">
2819 <title><literal>org.freedesktop.DBus.NameHasOwner</literal></title>
2823 BOOLEAN NameHasOwner (in STRING name)
2830 <entry>Argument</entry>
2832 <entry>Description</entry>
2838 <entry>STRING</entry>
2839 <entry>Name to check</entry>
2849 <entry>Argument</entry>
2851 <entry>Description</entry>
2857 <entry>BOOLEAN</entry>
2858 <entry>Return value, true if the name exists</entry>
2865 Checks if the specified name exists (currently has an owner).
2869 <sect3 id="bus-messages-name-owner-changed">
2870 <title><literal>org.freedesktop.DBus.NameOwnerChanged</literal></title>
2874 NameOwnerChanged (STRING name, STRING old_owner, STRING new_owner)
2881 <entry>Argument</entry>
2883 <entry>Description</entry>
2889 <entry>STRING</entry>
2890 <entry>Name with a new owner</entry>
2894 <entry>STRING</entry>
2895 <entry>Old owner or empty string if none</entry>
2899 <entry>STRING</entry>
2900 <entry>New owner or empty string if none</entry>
2907 This signal indicates that the owner of a name has changed.
2908 It's also the signal to use to detect the appearance of
2909 new names on the bus.
2912 <sect3 id="bus-messages-name-lost">
2913 <title><literal>org.freedesktop.DBus.NameLost</literal></title>
2917 NameLost (STRING name)
2924 <entry>Argument</entry>
2926 <entry>Description</entry>
2932 <entry>STRING</entry>
2933 <entry>Name which was lost</entry>
2940 This signal is sent to a specific application when it loses
2941 ownership of a name.
2945 <sect3 id="bus-messages-name-acquired">
2946 <title><literal>org.freedesktop.DBus.NameAcquired</literal></title>
2950 NameAcquired (STRING name)
2957 <entry>Argument</entry>
2959 <entry>Description</entry>
2965 <entry>STRING</entry>
2966 <entry>Name which was acquired</entry>
2973 This signal is sent to a specific application when it gains
2974 ownership of a name.
2978 <sect3 id="bus-messages-start-service-by-name">
2979 <title><literal>org.freedesktop.DBus.StartServiceByName</literal></title>
2983 UINT32 StartServiceByName (in STRING name, in UINT32 flags)
2990 <entry>Argument</entry>
2992 <entry>Description</entry>
2998 <entry>STRING</entry>
2999 <entry>Name of the service to start</entry>
3003 <entry>UINT32</entry>
3004 <entry>Flags (currently not used)</entry>
3014 <entry>Argument</entry>
3016 <entry>Description</entry>
3022 <entry>UINT32</entry>
3023 <entry>Return value</entry>
3028 Tries to launch the executable associated with a name. For more information, see <xref linkend="message-bus-starting-services"/>.
3032 The return value can be one of the following values:
3037 <entry>Identifier</entry>
3038 <entry>Value</entry>
3039 <entry>Description</entry>
3044 <entry>DBUS_START_REPLY_SUCCESS</entry>
3046 <entry>The service was successfully started.</entry>
3049 <entry>DBUS_START_REPLY_ALREADY_RUNNING</entry>
3051 <entry>A connection already owns the given name.</entry>
3060 <sect3 id="bus-messages-get-name-owner">
3061 <title><literal>org.freedesktop.DBus.GetNameOwner</literal></title>
3065 STRING GetNameOwner (in STRING name)
3072 <entry>Argument</entry>
3074 <entry>Description</entry>
3080 <entry>STRING</entry>
3081 <entry>Name to get the owner of</entry>
3091 <entry>Argument</entry>
3093 <entry>Description</entry>
3099 <entry>STRING</entry>
3100 <entry>Return value, a unique connection name</entry>
3105 Returns the unique connection name of the primary owner of the name
3106 given. If the requested name doesn't have an owner, returns a
3107 <literal>org.freedesktop.DBus.Error.NameHasNoOwner</literal> error.
3111 <sect3 id="bus-messages-get-connection-unix-user">
3112 <title><literal>org.freedesktop.DBus.GetConnectionUnixUser</literal></title>
3116 UINT32 GetConnectionUnixUser (in STRING connection_name)
3123 <entry>Argument</entry>
3125 <entry>Description</entry>
3131 <entry>STRING</entry>
3132 <entry>Name of the connection to query</entry>
3142 <entry>Argument</entry>
3144 <entry>Description</entry>
3150 <entry>UINT32</entry>
3151 <entry>unix user id</entry>
3156 Returns the unix uid of the process connected to the server. If unable to
3157 determine it, a <literal>org.freedesktop.DBus.Error.Failed</literal>
3166 <appendix id="implementation-notes">
3167 <title>Implementation notes</title>
3168 <sect1 id="implementation-notes-subsection">
3176 <glossary><title>Glossary</title>
3178 This glossary defines some of the terms used in this specification.
3181 <glossentry id="term-bus-name"><glossterm>Bus Name</glossterm>
3184 The message bus maintains an association between names and
3185 connections. (Normally, there's one connection per application.) A
3186 bus name is simply an identifier used to locate connections. For
3187 example, the hypothetical <literal>com.yoyodyne.Screensaver</literal>
3188 name might be used to send a message to a screensaver from Yoyodyne
3189 Corporation. An application is said to <firstterm>own</firstterm> a
3190 name if the message bus has associated the application's connection
3191 with the name. Names may also have <firstterm>queued
3192 owners</firstterm> (see <xref linkend="term-queued-owner"/>).
3193 The bus assigns a unique name to each connection,
3194 see <xref linkend="term-unique-name"/>. Other names
3195 can be thought of as "well-known names" and are
3196 used to find applications that offer specific functionality.
3201 <glossentry id="term-message"><glossterm>Message</glossterm>
3204 A message is the atomic unit of communication via the D-BUS
3205 protocol. It consists of a <firstterm>header</firstterm> and a
3206 <firstterm>body</firstterm>; the body is made up of
3207 <firstterm>arguments</firstterm>.
3212 <glossentry id="term-message-bus"><glossterm>Message Bus</glossterm>
3215 The message bus is a special application that forwards
3216 or routes messages between a group of applications
3217 connected to the message bus. It also manages
3218 <firstterm>names</firstterm> used for routing
3224 <glossentry id="term-name"><glossterm>Name</glossterm>
3227 See <xref linkend="term-bus-name"/>. "Name" may
3228 also be used to refer to some of the other names
3229 in D-BUS, such as interface names.
3234 <glossentry id="namespace"><glossterm>Namespace</glossterm>
3237 Used to prevent collisions when defining new interfaces or bus
3238 names. The convention used is the same one Java uses for defining
3239 classes: a reversed domain name.
3244 <glossentry id="term-object"><glossterm>Object</glossterm>
3247 Each application contains <firstterm>objects</firstterm>, which have
3248 <firstterm>interfaces</firstterm> and
3249 <firstterm>methods</firstterm>. Objects are referred to by a name,
3250 called a <firstterm>path</firstterm>.
3255 <glossentry id="one-to-one"><glossterm>One-to-One</glossterm>
3258 An application talking directly to another application, without going
3259 through a message bus. One-to-one connections may be "peer to peer" or
3260 "client to server." The D-BUS protocol has no concept of client
3261 vs. server after a connection has authenticated; the flow of messages
3262 is symmetrical (full duplex).
3267 <glossentry id="term-path"><glossterm>Path</glossterm>
3270 Object references (object names) in D-BUS are organized into a
3271 filesystem-style hierarchy, so each object is named by a path. As in
3272 LDAP, there's no difference between "files" and "directories"; a path
3273 can refer to an object, while still having child objects below it.
3278 <glossentry id="term-queued-owner"><glossterm>Queued Name Owner</glossterm>
3281 Each bus name has a primary owner; messages sent to the name go to the
3282 primary owner. However, certain names also maintain a queue of
3283 secondary owners "waiting in the wings." If the primary owner releases
3284 the name, then the first secondary owner in the queue automatically
3285 becomes the new owner of the name.
3290 <glossentry id="term-service"><glossterm>Service</glossterm>
3293 A service is an executable that can be launched by the bus daemon.
3294 Services normally guarantee some particular features, for example they
3295 may guarantee that they will request a specific name such as
3296 "org.freedesktop.Screensaver", have a singleton object
3297 "/org/freedesktop/Application", and that object will implement the
3298 interface "org.freedesktop.ScreensaverControl".
3303 <glossentry id="term-service-description-files"><glossterm>Service Description Files</glossterm>
3306 ".service files" tell the bus about service applications that can be
3307 launched (see <xref linkend="term-service"/>). Most importantly they
3308 provide a mapping from bus names to services that will request those
3309 names when they start up.
3314 <glossentry id="term-unique-name"><glossterm>Unique Connection Name</glossterm>
3317 The special name automatically assigned to each connection by the
3318 message bus. This name will never change owner, and will be unique
3319 (never reused during the lifetime of the message bus).
3320 It will begin with a ':' character.