<literal>org.freedesktop.DBus.RequestName</literal>

From 3492c747246efda1ca719422b3e681bdb3810c07 Mon Sep 17 00:00:00 2001 From: Tom Gundersen Date: Fri, 21 Apr 2017 11:54:03 +0200 Subject: [PATCH 1/3] docs: document all of the org.freedesktop.DBus methods together This patch simply moves RequestName, ReleaseName and ListNameOwners to the "Message Bus Messages" section. This keeps the documentation of the org.freedesktop.DBus interface in one place for easier reading. Only very minor rewording was done, but no substantive changes. Signed-off-by: Tom Gundersen --- doc/dbus-specification.xml | 2257 ++++++++++++++++++++++---------------------- 1 file changed, 1125 insertions(+), 1132 deletions(-) diff --git a/doc/dbus-specification.xml b/doc/dbus-specification.xml index 0f0ca5ae..7759de36 100644 --- a/doc/dbus-specification.xml +++ b/doc/dbus-specification.xml @@ -4253,1036 +4253,645 @@ name. These names can be released again using the org.freedesktop.DBus.ReleaseName message. + - - <literal>org.freedesktop.DBus.RequestName</literal> + + Message Bus Message Routing + + + Messages may have a DESTINATION field (see ), resulting in a + unicast message. If the + DESTINATION field is present, it specifies a message + recipient by name. Method calls and replies normally specify this field. + The message bus must send messages (of any type) with the + DESTINATION field set to the specified recipient, + regardless of whether the recipient has set up a match rule matching + the message. + + + + When the message bus receives a signal, if the + DESTINATION field is absent, it is considered to + be a broadcast signal, and is sent to all + applications with message matching rules that + match the message. Most signal messages are broadcasts, and + no other message types currently defined in this specification + may be broadcast. + + + + Unicast signal messages (those with a DESTINATION + field) are not commonly used, but they are treated like any unicast + message: they are delivered to the specified receipient, + regardless of its match rules. One use for unicast signals is to + avoid a race condition in which a signal is emitted before the intended + recipient can call to + receive that signal: if the signal is sent directly to that recipient + using a unicast message, it does not need to add a match rule at all, + and there is no race condition. Another use for unicast signals, + on message buses whose security policy prevents eavesdropping, is to + send sensitive information which should only be visible to one + recipient. + + + + When the message bus receives a method call, if the + DESTINATION field is absent, the call is taken to be + a standard one-to-one message and interpreted by the message bus + itself. For example, sending an + org.freedesktop.DBus.Peer.Ping message with no + DESTINATION will cause the message bus itself to + reply to the ping immediately; the message bus will not make this + message visible to other applications. + + + + Continuing the org.freedesktop.DBus.Peer.Ping example, if + the ping message were sent with a DESTINATION name of + com.yoyodyne.Screensaver, then the ping would be + forwarded, and the Yoyodyne Corporation screensaver application would be + expected to reply to the ping. + + + + Message bus implementations may impose a security policy which + prevents certain messages from being sent or received. + When a method call message cannot be sent or received due to a security + policy, the message bus should send an error reply, unless the + original message had the NO_REPLY flag. + + + + Eavesdropping - As a method: - - UINT32 RequestName (in STRING name, in UINT32 flags) - - Message arguments: + Receiving a unicast message whose DESTINATION + indicates a different recipient is called + eavesdropping. On a message bus which acts as + a security boundary (like the standard system bus), the security + policy should usually prevent eavesdropping, since unicast messages + are normally kept private and may contain security-sensitive + information. + + + + Eavesdropping is mainly useful for debugging tools, such as + the dbus-monitor tool in the reference + implementation of D-Bus. Tools which eavesdrop on the message bus + should be careful to avoid sending a reply or error in response to + messages intended for a different client. + + + + Clients may attempt to eavesdrop by adding match rules + (see ) containing + the eavesdrop='true' match. If the message bus' + security policy does not allow eavesdropping, the match rule can + still be added, but will not have any practical effect. For + compatibility with older message bus implementations, if adding such + a match rule results in an error reply, the client may fall back to + adding the same rule with the eavesdrop match + omitted. + + + + Eavesdropping interacts poorly with buses with non-trivial + access control restrictions. The + method provides + an alternative way to monitor buses. + + + + + Match Rules + + An important part of the message bus routing protocol is match + rules. Match rules describe the messages that should be sent to a + client, based on the contents of the message. Broadcast signals + are only sent to clients which have a suitable match rule: this + avoids waking up client processes to deal with signals that are + not relevant to that client. + + + Messages that list a client as their DESTINATION + do not need to match the client's match rules, and are sent to that + client regardless. As a result, match rules are mainly used to + receive a subset of broadcast signals. + + + Match rules can also be used for eavesdropping + (see ), + if the security policy of the message bus allows it. + + + Match rules are added using the AddMatch bus method + (see ). Rules are + specified as a string of comma separated key/value pairs. + Excluding a key from the rule indicates a wildcard match. + For instance excluding the the member from a match rule but + adding a sender would let all messages from that sender through. + An example of a complete rule would be + "type='signal',sender='org.freedesktop.DBus',interface='org.freedesktop.DBus',member='Foo',path='/bar/foo',destination=':452345.34',arg2='bar'" + + + Within single quotes (ASCII apostrophe, U+0027), a backslash + (U+005C) represents itself, and an apostrophe ends the quoted + section. Outside single quotes, \' (backslash, apostrophe) + represents an apostrophe, and any backslash not followed by + an apostrophe represents itself. For instance, the match rules + arg0=''\''',arg1='\',arg2=',',arg3='\\' and + arg0=\',arg1=\,arg2=',',arg3=\\ + both match messages where the arguments are a 1-character string + containing an apostrophe, a 1-character string containing a + backslash, a 1-character string containing a comma, and a + 2-character string containing two backslashes + + This idiosyncratic quoting style is based on the rules for + escaping items to appear inside single-quoted strings + in POSIX /bin/sh, but please + note that backslashes that are not inside single quotes have + different behaviour. This syntax does not offer any way to + represent an apostrophe inside single quotes (it is necessary + to leave the single-quoted section, backslash-escape the + apostrophe and re-enter single quotes), or to represent a + comma outside single quotes (it is necessary to wrap it in + a single-quoted section). + + . + + + The following table describes the keys that can be used to create + a match rule. - Argument - Type + Key + Possible Values Description - 0 - STRING - Name to request + type + 'signal', 'method_call', 'method_return', 'error' + Match on the message type. An example of a type match is type='signal' - 1 - UINT32 - Flags + sender + A bus or unique name (see + and respectively) + + Match messages sent by a particular sender. An example of a sender match + is sender='org.freedesktop.Hal' - - - - Reply arguments: - - - - Argument - Type - Description + interface + An interface name (see ) + Match messages sent over or to a particular interface. An example of an + interface match is interface='org.freedesktop.Hal.Manager'. + If a message omits the interface header, it must not match any rule + that specifies this key. - - - 0 - UINT32 - Return value + member + Any valid method or signal name + Matches messages which have the give method or signal name. An example of + a member match is member='NameOwnerChanged' - - - - - - This method call should be sent to - org.freedesktop.DBus and asks the message bus to - assign the given name to the method caller. Each name maintains a - queue of possible owners, where the head of the queue is the primary - or current owner of the name. Each potential owner in the queue - maintains the DBUS_NAME_FLAG_ALLOW_REPLACEMENT and - DBUS_NAME_FLAG_DO_NOT_QUEUE settings from its latest RequestName - call. When RequestName is invoked the following occurs: - - - - If the method caller is currently the primary owner of the name, - the DBUS_NAME_FLAG_ALLOW_REPLACEMENT and DBUS_NAME_FLAG_DO_NOT_QUEUE - values are updated with the values from the new RequestName call, - and nothing further happens. - - + + path + An object path (see ) + Matches messages which are sent from or to the given object. An example of a + path match is path='/org/freedesktop/Hal/Manager' + + + path_namespace + An object path + + + Matches messages which are sent from or to an + object for which the object path is either the + given value, or that value followed by one or + more path components. + - - - If the current primary owner (head of the queue) has - DBUS_NAME_FLAG_ALLOW_REPLACEMENT set, and the RequestName - invocation has the DBUS_NAME_FLAG_REPLACE_EXISTING flag, then - the caller of RequestName replaces the current primary owner at - the head of the queue and the current primary owner moves to the - second position in the queue. If the caller of RequestName was - in the queue previously its flags are updated with the values from - the new RequestName in addition to moving it to the head of the queue. - - - - - - If replacement is not possible, and the method caller is - currently in the queue but not the primary owner, its flags are - updated with the values from the new RequestName call. - - - - - - If replacement is not possible, and the method caller is - currently not in the queue, the method caller is appended to the - queue. - - + + For example, + path_namespace='/com/example/foo' + would match signals sent by + /com/example/foo + or by + /com/example/foo/bar, + but not by + /com/example/foobar. + - - - If any connection in the queue has DBUS_NAME_FLAG_DO_NOT_QUEUE - set and is not the primary owner, it is removed from the - queue. This can apply to the previous primary owner (if it - was replaced) or the method caller (if it updated the - DBUS_NAME_FLAG_DO_NOT_QUEUE flag while still stuck in the - queue, or if it was just added to the queue with that flag set). - - - - - - Note that DBUS_NAME_FLAG_REPLACE_EXISTING results in "jumping the - queue," even if another application already in the queue had specified - DBUS_NAME_FLAG_REPLACE_EXISTING. This comes up if a primary owner - that does not allow replacement goes away, and the next primary owner - does allow replacement. In this case, queued items that specified - DBUS_NAME_FLAG_REPLACE_EXISTING do not - automatically replace the new primary owner. In other words, - DBUS_NAME_FLAG_REPLACE_EXISTING is not saved, it is only used at the - time RequestName is called. This is deliberate to avoid an infinite loop - anytime two applications are both DBUS_NAME_FLAG_ALLOW_REPLACEMENT - and DBUS_NAME_FLAG_REPLACE_EXISTING. - - - The flags argument contains any of the following values logically ORed - together: + + Using both path and + path_namespace in the same match + rule is not allowed. + - - - + + + This match key was added in version 0.16 of the + D-Bus specification and implemented by the bus + daemon in dbus 1.5.0 and later. + + + + - Conventional Name - Value - Description + destination + A unique name (see ) + Matches messages which are being sent to the given unique name. An + example of a destination match is destination=':1.0' - - - DBUS_NAME_FLAG_ALLOW_REPLACEMENT - 0x1 + arg[0, 1, 2, 3, ...] + Any string + Arg matches are special and are used for further restricting the + match based on the arguments in the body of a message. Only arguments of type + STRING can be matched in this way. An example of an argument match + would be arg3='Foo'. Only argument indexes from 0 to 63 should be + accepted. + + + arg[0, 1, 2, 3, ...]path + Any string + Argument path matches provide a specialised form of wildcard matching for + path-like namespaces. They can match arguments whose type is either STRING or + OBJECT_PATH. As with normal argument matches, + if the argument is exactly equal to the string given in the match + rule then the rule is satisfied. Additionally, there is also a + match when either the string given in the match rule or the + appropriate message argument ends with '/' and is a prefix of the + other. An example argument path match is arg0path='/aa/bb/'. This + would match messages with first arguments of '/', '/aa/', + '/aa/bb/', '/aa/bb/cc/' and '/aa/bb/cc'. It would not match + messages with first arguments of '/aa/b', '/aa' or even '/aa/bb'. - If an application A specifies this flag and succeeds in - becoming the owner of the name, and another application B - later calls RequestName with the - DBUS_NAME_FLAG_REPLACE_EXISTING flag, then application A - will lose ownership and receive a - org.freedesktop.DBus.NameLost signal, and - application B will become the new owner. If DBUS_NAME_FLAG_ALLOW_REPLACEMENT - is not specified by application A, or DBUS_NAME_FLAG_REPLACE_EXISTING - is not specified by application B, then application B will not replace - application A as the owner. - + This is intended for monitoring “directories” in file system-like + hierarchies, as used in the dconf configuration + system. An application interested in all nodes in a particular hierarchy would + monitor arg0path='/ca/example/foo/'. Then the service could + emit a signal with zeroth argument "/ca/example/foo/bar" to + represent a modification to the “bar” property, or a signal with zeroth + argument "/ca/example/" to represent atomic modification of + many properties within that directory, and the interested application would be + notified in both cases. + + + This match key was added in version 0.12 of the + D-Bus specification, implemented for STRING + arguments by the bus daemon in dbus 1.2.0 and later, + and implemented for OBJECT_PATH arguments in dbus 1.5.0 + and later. + + - DBUS_NAME_FLAG_REPLACE_EXISTING - 0x2 + arg0namespace + Like a bus name, except that the string is not + required to contain a '.' (period) + Match messages whose first argument is of type STRING, and is a bus name + or interface name within the specified namespace. This is primarily intended + for watching name owner changes for a group of related bus names, rather than + for a single name or all name changes. - Try to replace the current owner if there is one. If this - flag is not set the application will only become the owner of - the name if there is no current owner. If this flag is set, - the application will replace the current owner if - the current owner specified DBUS_NAME_FLAG_ALLOW_REPLACEMENT. + Because every valid interface name is also a valid + bus name, this can also be used for messages whose + first argument is an interface name. + + For example, the match rule + member='NameOwnerChanged',arg0namespace='com.example.backend1' + matches name owner changes for bus names such as + com.example.backend1.foo, + com.example.backend1.foo.bar, and + com.example.backend1 itself. + See also . + + + This match key was added in version 0.16 of the + D-Bus specification and implemented by the bus + daemon in dbus 1.5.0 and later. + + - DBUS_NAME_FLAG_DO_NOT_QUEUE - 0x4 - - - Without this flag, if an application requests a name that is - already owned, the application will be placed in a queue to - own the name when the current owner gives it up. If this - flag is given, the application will not be placed in the - queue, the request for the name will simply fail. This flag - also affects behavior when an application is replaced as - name owner; by default the application moves back into the - waiting queue, unless this flag was provided when the application - became the name owner. - + eavesdrop + 'true', 'false' + Since D-Bus 1.5.6, match rules do not + match messages which have a DESTINATION + field unless the match rule specifically + requests this + (see ) + by specifying eavesdrop='true' + in the match rule. eavesdrop='false' + restores the default behaviour. Messages are + delivered to their DESTINATION + regardless of match rules, so this match does not + affect normal delivery of unicast messages. + If the message bus has a security policy which forbids + eavesdropping, this match may still be used without error, + but will not have any practical effect. + In older versions of D-Bus, this match was not allowed + in match rules, and all match rules behaved as if + eavesdrop='true' had been used. + + + + + Message Bus Starting Services (Activation) + + The message bus can start applications on behalf of other applications. + This is referred to as service activation or + activation. + An application that can be started in this way is called a + service or an + activatable service. + - The return code can be one of the following values: + + Starting a service should be read as synonymous + with service activation. + - - - - - Conventional Name - Value - Description - - - - - DBUS_REQUEST_NAME_REPLY_PRIMARY_OWNER - 1 The caller is now the primary owner of - the name, replacing any previous owner. Either the name had no - owner before, or the caller specified - DBUS_NAME_FLAG_REPLACE_EXISTING and the current owner specified - DBUS_NAME_FLAG_ALLOW_REPLACEMENT. - - - DBUS_REQUEST_NAME_REPLY_IN_QUEUE - 2 - - The name already had an owner, - DBUS_NAME_FLAG_DO_NOT_QUEUE was not specified, and either - the current owner did not specify - DBUS_NAME_FLAG_ALLOW_REPLACEMENT or the requesting - application did not specify DBUS_NAME_FLAG_REPLACE_EXISTING. - - - - DBUS_REQUEST_NAME_REPLY_EXISTS 3 - The name already has an owner, - DBUS_NAME_FLAG_DO_NOT_QUEUE was specified, and either - DBUS_NAME_FLAG_ALLOW_REPLACEMENT was not specified by the - current owner, or DBUS_NAME_FLAG_REPLACE_EXISTING was not - specified by the requesting application. - - - DBUS_REQUEST_NAME_REPLY_ALREADY_OWNER - 4 - The application trying to request ownership of a name is already the owner of it. - - - - - - - - - <literal>org.freedesktop.DBus.ReleaseName</literal> - - As a method: - - UINT32 ReleaseName (in STRING name) - - Message arguments: - - - - - Argument - Type - Description - - - - - 0 - STRING - Name to release - - - - - Reply arguments: - - - - - Argument - Type - Description - - - - - 0 - UINT32 - Return value - - - - - - - This method call should be sent to - org.freedesktop.DBus and asks the message bus to - release the method caller's claim to the given name. If the caller is - the primary owner, a new primary owner will be selected from the - queue if any other owners are waiting. If the caller is waiting in - the queue for the name, the caller will removed from the queue and - will not be made an owner of the name if it later becomes available. - If there are no other owners in the queue for the name, it will be - removed from the bus entirely. - - The return code can be one of the following values: - - - - - - Conventional Name - Value - Description - - - - - DBUS_RELEASE_NAME_REPLY_RELEASED - 1 The caller has released his claim on - the given name. Either the caller was the primary owner of - the name, and the name is now unused or taken by somebody - waiting in the queue for the name, or the caller was waiting - in the queue for the name and has now been removed from the - queue. - - - DBUS_RELEASE_NAME_REPLY_NON_EXISTENT - 2 - The given name does not exist on this bus. - - - DBUS_RELEASE_NAME_REPLY_NOT_OWNER - 3 - The caller was not the primary owner of this name, - and was also not waiting in the queue to own this name. - - - - - - - - - <literal>org.freedesktop.DBus.ListQueuedOwners</literal> - - As a method: - - ARRAY of STRING ListQueuedOwners (in STRING name) - - Message arguments: - - - - - Argument - Type - Description - - - - - 0 - STRING - The well-known bus name to query, such as - com.example.cappuccino - - - - - Reply arguments: - - - - - Argument - Type - Description - - - - - 0 - ARRAY of STRING - The unique bus names of connections currently queued - for the name - - - - - - - This method call should be sent to - org.freedesktop.DBus and lists the connections - currently queued for a bus name (see - ). - - - - - - Message Bus Message Routing + + In D-Bus, service activation is normally done by + auto-starting. + In auto-starting, applications send a + message to a particular well-known name, such as + com.example.TextEditor1, without specifying the + NO_AUTO_START flag in the message header. + If no application on the bus owns the requested name, but the bus + daemon does know how to start an activatable service for that name, + then the bus daemon will start that service, wait for it to request + that name, and deliver the message to it. + - Messages may have a DESTINATION field (see ), resulting in a - unicast message. If the - DESTINATION field is present, it specifies a message - recipient by name. Method calls and replies normally specify this field. - The message bus must send messages (of any type) with the - DESTINATION field set to the specified recipient, - regardless of whether the recipient has set up a match rule matching - the message. + It is also possible for applications to send an explicit request to + start a service: this is another form of activation, distinct from + auto-starting. See + for details. - When the message bus receives a signal, if the - DESTINATION field is absent, it is considered to - be a broadcast signal, and is sent to all - applications with message matching rules that - match the message. Most signal messages are broadcasts, and - no other message types currently defined in this specification - may be broadcast. + In either case, this implies a contract documented along with the name + com.example.TextEditor1 for which object + the owner of that name will provide, and what interfaces those + objects will have. - Unicast signal messages (those with a DESTINATION - field) are not commonly used, but they are treated like any unicast - message: they are delivered to the specified receipient, - regardless of its match rules. One use for unicast signals is to - avoid a race condition in which a signal is emitted before the intended - recipient can call to - receive that signal: if the signal is sent directly to that recipient - using a unicast message, it does not need to add a match rule at all, - and there is no race condition. Another use for unicast signals, - on message buses whose security policy prevents eavesdropping, is to - send sensitive information which should only be visible to one - recipient. + To find an executable corresponding to a particular name, the bus daemon + looks for service description files. Service + description files define a mapping from names to executables. Different + kinds of message bus will look for these files in different places, see + . - - When the message bus receives a method call, if the - DESTINATION field is absent, the call is taken to be - a standard one-to-one message and interpreted by the message bus - itself. For example, sending an - org.freedesktop.DBus.Peer.Ping message with no - DESTINATION will cause the message bus itself to - reply to the ping immediately; the message bus will not make this - message visible to other applications. + Service description files have the ".service" file + extension. The message bus will only load service description files + ending with .service; all other files will be ignored. The file format + is similar to that of desktop + entries. All service description files must be in UTF-8 + encoding. To ensure that there will be no name collisions, service files + must be namespaced using the same mechanism as messages and service + names. - Continuing the org.freedesktop.DBus.Peer.Ping example, if - the ping message were sent with a DESTINATION name of - com.yoyodyne.Screensaver, then the ping would be - forwarded, and the Yoyodyne Corporation screensaver application would be - expected to reply to the ping. + On the well-known system bus, the name of a service description file + must be its well-known name plus .service, + for instance + com.example.ConfigurationDatabase1.service. - Message bus implementations may impose a security policy which - prevents certain messages from being sent or received. - When a method call message cannot be sent or received due to a security - policy, the message bus should send an error reply, unless the - original message had the NO_REPLY flag. + On the well-known session bus, services should follow the same + service description file naming convention as on the system bus, + but for backwards compatibility they are not required to do so. - - Eavesdropping - - Receiving a unicast message whose DESTINATION - indicates a different recipient is called - eavesdropping. On a message bus which acts as - a security boundary (like the standard system bus), the security - policy should usually prevent eavesdropping, since unicast messages - are normally kept private and may contain security-sensitive - information. - - - - Eavesdropping is mainly useful for debugging tools, such as - the dbus-monitor tool in the reference - implementation of D-Bus. Tools which eavesdrop on the message bus - should be careful to avoid sending a reply or error in response to - messages intended for a different client. + + [FIXME the file format should be much better specified than "similar to + .desktop entries" esp. since desktop entries are already + badly-specified. ;-)] + These sections from the specification apply to service files as well: + + + General syntax + Comment format + + + Service description files must contain a + D-BUS Service group with at least the keys + Name (the well-known name of the service) + and Exec (the command to be executed). + +

+ Example service description file + + # Sample service description file + [D-BUS Service] + Name=com.example.ConfigurationDatabase1 + Exec=/usr/bin/sample-configd + + + + + + Additionally, service description files for the well-known system + bus on Unix must contain a User key, whose value + is the name of a user account (e.g. root). + The system service will be run as that user. + + + + When an application asks to start a service by name, the bus daemon tries to + find a service that will own that name. It then tries to spawn the + executable associated with it. If this fails, it will report an + error. + + + + On the well-known system bus, it is not possible for two .service files + in the same directory to offer the same service, because they are + constrained to have names that match the service name. + + + + On the well-known session bus, if two .service files in the same + directory offer the same service name, the result is undefined. + Distributors should avoid this situation, for instance by naming + session services' .service files according to their service name. + + + + If two .service files in different directories offer the same + service name, the one in the higher-priority directory is used: + for instance, on the system bus, .service files in + /usr/local/share/dbus-1/system-services take precedence over those + in /usr/share/dbus-1/system-services. + + + The executable launched will have the environment variable + DBUS_STARTER_ADDRESS set to the address of the + message bus so it can connect and request the appropriate names. + + + The executable being launched may want to know whether the message bus + starting it is one of the well-known message buses (see ). To facilitate this, the bus must also set + the DBUS_STARTER_BUS_TYPE environment variable if it is one + of the well-known buses. The currently-defined values for this variable + are system for the systemwide message bus, + and session for the per-login-session message + bus. The new executable must still connect to the address given + in DBUS_STARTER_ADDRESS, but may assume that the + resulting connection is to the well-known bus. + + + [FIXME there should be a timeout somewhere, either specified + in the .service file, by the client, or just a global value + and if the client being activated fails to connect within that + timeout, an error should be sent back.] + + + + Message Bus Service Scope + + The "scope" of a service is its "per-", such as per-session, + per-machine, per-home-directory, or per-display. The reference + implementation doesn't yet support starting services in a different + scope from the message bus itself. So e.g. if you start a service + on the session bus its scope is per-session. + + + We could add an optional scope to a bus name. For example, for + per-(display,session pair), we could have a unique ID for each display + generated automatically at login and set on screen 0 by executing a + special "set display ID" binary. The ID would be stored in a + _DBUS_DISPLAY_ID property and would be a string of + random bytes. This ID would then be used to scope names. + Starting/locating a service could be done by ID-name pair rather than + only by name. + + + Contrast this with a per-display scope. To achieve that, we would + want a single bus spanning all sessions using a given display. + So we might set a _DBUS_DISPLAY_BUS_ADDRESS + property on screen 0 of the display, pointing to this bus. + + + + systemd Activation - Clients may attempt to eavesdrop by adding match rules - (see ) containing - the eavesdrop='true' match. If the message bus' - security policy does not allow eavesdropping, the match rule can - still be added, but will not have any practical effect. For - compatibility with older message bus implementations, if adding such - a match rule results in an error reply, the client may fall back to - adding the same rule with the eavesdrop match - omitted. + Service description files may contain a + SystemdService key. Its value is the name of a + systemd + service, for example + dbus-com.example.MyDaemon.service. - Eavesdropping interacts poorly with buses with non-trivial - access control restrictions. The - method provides - an alternative way to monitor buses. + If this key is present, the bus daemon may carry out activation for + this D-Bus service by sending a request to systemd asking it to + start the systemd service whose name is the value of + SystemdService. For example, the reference + dbus-daemon has a + --systemd-activation option that enables this + feature, and that option is given when it is started by systemd. + + + + On the well-known system bus, it is a common practice to set + SystemdService to dbus-, + followed by the well-known bus name, followed by + .service, then register that name as an alias + for the real systemd service. This allows D-Bus activation of a + service to be enabled or disabled independently of whether the + service is started by systemd during boot. - - Match Rules + + Mediating Activation with AppArmor + - An important part of the message bus routing protocol is match - rules. Match rules describe the messages that should be sent to a - client, based on the contents of the message. Broadcast signals - are only sent to clients which have a suitable match rule: this - avoids waking up client processes to deal with signals that are - not relevant to that client. + Please refer to + AppArmor documentation + for general information on AppArmor, and how it mediates D-Bus + messages when used in conjunction with a kernel and + dbus-daemon that support this. + - Messages that list a client as their DESTINATION - do not need to match the client's match rules, and are sent to that - client regardless. As a result, match rules are mainly used to - receive a subset of broadcast signals. + In recent versions of the reference dbus-daemon, + AppArmor policy rules of type dbus send + are also used to control auto-starting: if a message is sent to + the well-known name of an activatable service, the + dbus-daemon will attempt to determine whether + it would deliver the message to that service + beforeauto-starting it, by making some + assumptions about the resulting process's credentials. + - Match rules can also be used for eavesdropping - (see ), - if the security policy of the message bus allows it. + If it does proceed with auto-starting, when the service appears, the + dbus-daemon repeats the policy check (with + the service's true credentials, which might not be identical) + before delivering the message. In practice, this second check will + usually be more strict than the first; the first check would only + be more strict if there are "blacklist"-style rules like + deny dbus send peer=(label=/usr/bin/protected) + that match on the peer's specific credentials, but AppArmor is + normally used in a "whitelist" style where this does not apply. + - Match rules are added using the AddMatch bus method - (see ). Rules are - specified as a string of comma separated key/value pairs. - Excluding a key from the rule indicates a wildcard match. - For instance excluding the the member from a match rule but - adding a sender would let all messages from that sender through. - An example of a complete rule would be - "type='signal',sender='org.freedesktop.DBus',interface='org.freedesktop.DBus',member='Foo',path='/bar/foo',destination=':452345.34',arg2='bar'" + To support this process, service description files may contain a + AssumedAppArmorLabel key. Its value is the name + of an AppArmor label, for example + /usr/sbin/mydaemon. + If present, AppArmor mediation of messages that auto-start a + service will decide whether to allow auto-starting to occur based + on the assumption that the activated service will be confined + under the specified label; in particular, rules of the form + dbus send peer=(label=/usr/sbin/mydaemon) or + deny dbus send peer=(label=/usr/sbin/mydaemon) + will match it, allowing or denying as appropriate + (even if there is in fact no profile of that name loaded). + - Within single quotes (ASCII apostrophe, U+0027), a backslash - (U+005C) represents itself, and an apostrophe ends the quoted - section. Outside single quotes, \' (backslash, apostrophe) - represents an apostrophe, and any backslash not followed by - an apostrophe represents itself. For instance, the match rules - arg0=''\''',arg1='\',arg2=',',arg3='\\' and - arg0=\',arg1=\,arg2=',',arg3=\\ - both match messages where the arguments are a 1-character string - containing an apostrophe, a 1-character string containing a - backslash, a 1-character string containing a comma, and a - 2-character string containing two backslashes - - This idiosyncratic quoting style is based on the rules for - escaping items to appear inside single-quoted strings - in POSIX /bin/sh, but please - note that backslashes that are not inside single quotes have - different behaviour. This syntax does not offer any way to - represent an apostrophe inside single quotes (it is necessary - to leave the single-quoted section, backslash-escape the - apostrophe and re-enter single quotes), or to represent a - comma outside single quotes (it is necessary to wrap it in - a single-quoted section). - - . + Otherwise, AppArmor mediation of messages that auto-start a + service will decide whether to allow auto-starting to occur + without specifying any particular label. In particular, any rule of + the form dbus send peer=(label=X) or + deny dbus send peer=(label=X) + (for any value of X, including the special label + unconfined) will not influence whether the + auto-start is allowed. - - The following table describes the keys that can be used to create - a match rule. - - - - - Key - Possible Values - Description - - - - - type - 'signal', 'method_call', 'method_return', 'error' - Match on the message type. An example of a type match is type='signal' - - - sender - A bus or unique name (see - and respectively) - - Match messages sent by a particular sender. An example of a sender match - is sender='org.freedesktop.Hal' - - - interface - An interface name (see ) - Match messages sent over or to a particular interface. An example of an - interface match is interface='org.freedesktop.Hal.Manager'. - If a message omits the interface header, it must not match any rule - that specifies this key. - - - member - Any valid method or signal name - Matches messages which have the give method or signal name. An example of - a member match is member='NameOwnerChanged' - - - path - An object path (see ) - Matches messages which are sent from or to the given object. An example of a - path match is path='/org/freedesktop/Hal/Manager' - - - path_namespace - An object path - - - Matches messages which are sent from or to an - object for which the object path is either the - given value, or that value followed by one or - more path components. - - - - For example, - path_namespace='/com/example/foo' - would match signals sent by - /com/example/foo - or by - /com/example/foo/bar, - but not by - /com/example/foobar. - - - - Using both path and - path_namespace in the same match - rule is not allowed. - - - - - This match key was added in version 0.16 of the - D-Bus specification and implemented by the bus - daemon in dbus 1.5.0 and later. - - - - - - destination - A unique name (see ) - Matches messages which are being sent to the given unique name. An - example of a destination match is destination=':1.0' - - - arg[0, 1, 2, 3, ...] - Any string - Arg matches are special and are used for further restricting the - match based on the arguments in the body of a message. Only arguments of type - STRING can be matched in this way. An example of an argument match - would be arg3='Foo'. Only argument indexes from 0 to 63 should be - accepted. - - - arg[0, 1, 2, 3, ...]path - Any string - - Argument path matches provide a specialised form of wildcard matching for - path-like namespaces. They can match arguments whose type is either STRING or - OBJECT_PATH. As with normal argument matches, - if the argument is exactly equal to the string given in the match - rule then the rule is satisfied. Additionally, there is also a - match when either the string given in the match rule or the - appropriate message argument ends with '/' and is a prefix of the - other. An example argument path match is arg0path='/aa/bb/'. This - would match messages with first arguments of '/', '/aa/', - '/aa/bb/', '/aa/bb/cc/' and '/aa/bb/cc'. It would not match - messages with first arguments of '/aa/b', '/aa' or even '/aa/bb'. - - This is intended for monitoring “directories” in file system-like - hierarchies, as used in the dconf configuration - system. An application interested in all nodes in a particular hierarchy would - monitor arg0path='/ca/example/foo/'. Then the service could - emit a signal with zeroth argument "/ca/example/foo/bar" to - represent a modification to the “bar” property, or a signal with zeroth - argument "/ca/example/" to represent atomic modification of - many properties within that directory, and the interested application would be - notified in both cases. - - - This match key was added in version 0.12 of the - D-Bus specification, implemented for STRING - arguments by the bus daemon in dbus 1.2.0 and later, - and implemented for OBJECT_PATH arguments in dbus 1.5.0 - and later. - - - - - - arg0namespace - Like a bus name, except that the string is not - required to contain a '.' (period) - - Match messages whose first argument is of type STRING, and is a bus name - or interface name within the specified namespace. This is primarily intended - for watching name owner changes for a group of related bus names, rather than - for a single name or all name changes. - - Because every valid interface name is also a valid - bus name, this can also be used for messages whose - first argument is an interface name. - - For example, the match rule - member='NameOwnerChanged',arg0namespace='com.example.backend1' - matches name owner changes for bus names such as - com.example.backend1.foo, - com.example.backend1.foo.bar, and - com.example.backend1 itself. - - See also . - - - This match key was added in version 0.16 of the - D-Bus specification and implemented by the bus - daemon in dbus 1.5.0 and later. - - - - - - eavesdrop - 'true', 'false' - Since D-Bus 1.5.6, match rules do not - match messages which have a DESTINATION - field unless the match rule specifically - requests this - (see ) - by specifying eavesdrop='true' - in the match rule. eavesdrop='false' - restores the default behaviour. Messages are - delivered to their DESTINATION - regardless of match rules, so this match does not - affect normal delivery of unicast messages. - If the message bus has a security policy which forbids - eavesdropping, this match may still be used without error, - but will not have any practical effect. - In older versions of D-Bus, this match was not allowed - in match rules, and all match rules behaved as if - eavesdrop='true' had been used. - - - - - - - - - - Message Bus Starting Services (Activation) - - The message bus can start applications on behalf of other applications. - This is referred to as service activation or - activation. - An application that can be started in this way is called a - service or an - activatable service. - - - - Starting a service should be read as synonymous - with service activation. - - - - In D-Bus, service activation is normally done by - auto-starting. - In auto-starting, applications send a - message to a particular well-known name, such as - com.example.TextEditor1, without specifying the - NO_AUTO_START flag in the message header. - If no application on the bus owns the requested name, but the bus - daemon does know how to start an activatable service for that name, - then the bus daemon will start that service, wait for it to request - that name, and deliver the message to it. - - - - It is also possible for applications to send an explicit request to - start a service: this is another form of activation, distinct from - auto-starting. See - for details. - - - - In either case, this implies a contract documented along with the name - com.example.TextEditor1 for which object - the owner of that name will provide, and what interfaces those - objects will have. - - - - To find an executable corresponding to a particular name, the bus daemon - looks for service description files. Service - description files define a mapping from names to executables. Different - kinds of message bus will look for these files in different places, see - . - - - Service description files have the ".service" file - extension. The message bus will only load service description files - ending with .service; all other files will be ignored. The file format - is similar to that of desktop - entries. All service description files must be in UTF-8 - encoding. To ensure that there will be no name collisions, service files - must be namespaced using the same mechanism as messages and service - names. - - - - On the well-known system bus, the name of a service description file - must be its well-known name plus .service, - for instance - com.example.ConfigurationDatabase1.service. - - - - On the well-known session bus, services should follow the same - service description file naming convention as on the system bus, - but for backwards compatibility they are not required to do so. - - - - [FIXME the file format should be much better specified than "similar to - .desktop entries" esp. since desktop entries are already - badly-specified. ;-)] - These sections from the specification apply to service files as well: - - - General syntax - Comment format - - - Service description files must contain a - D-BUS Service group with at least the keys - Name (the well-known name of the service) - and Exec (the command to be executed). - -

- Example service description file - - # Sample service description file - [D-BUS Service] - Name=com.example.ConfigurationDatabase1 - Exec=/usr/bin/sample-configd - - - - - - Additionally, service description files for the well-known system - bus on Unix must contain a User key, whose value - is the name of a user account (e.g. root). - The system service will be run as that user. - - - - When an application asks to start a service by name, the bus daemon tries to - find a service that will own that name. It then tries to spawn the - executable associated with it. If this fails, it will report an - error. - - - - On the well-known system bus, it is not possible for two .service files - in the same directory to offer the same service, because they are - constrained to have names that match the service name. - - - - On the well-known session bus, if two .service files in the same - directory offer the same service name, the result is undefined. - Distributors should avoid this situation, for instance by naming - session services' .service files according to their service name. - - - - If two .service files in different directories offer the same - service name, the one in the higher-priority directory is used: - for instance, on the system bus, .service files in - /usr/local/share/dbus-1/system-services take precedence over those - in /usr/share/dbus-1/system-services. - - - The executable launched will have the environment variable - DBUS_STARTER_ADDRESS set to the address of the - message bus so it can connect and request the appropriate names. - - - The executable being launched may want to know whether the message bus - starting it is one of the well-known message buses (see ). To facilitate this, the bus must also set - the DBUS_STARTER_BUS_TYPE environment variable if it is one - of the well-known buses. The currently-defined values for this variable - are system for the systemwide message bus, - and session for the per-login-session message - bus. The new executable must still connect to the address given - in DBUS_STARTER_ADDRESS, but may assume that the - resulting connection is to the well-known bus. - - - [FIXME there should be a timeout somewhere, either specified - in the .service file, by the client, or just a global value - and if the client being activated fails to connect within that - timeout, an error should be sent back.] - - - - Message Bus Service Scope - - The "scope" of a service is its "per-", such as per-session, - per-machine, per-home-directory, or per-display. The reference - implementation doesn't yet support starting services in a different - scope from the message bus itself. So e.g. if you start a service - on the session bus its scope is per-session. - - - We could add an optional scope to a bus name. For example, for - per-(display,session pair), we could have a unique ID for each display - generated automatically at login and set on screen 0 by executing a - special "set display ID" binary. The ID would be stored in a - _DBUS_DISPLAY_ID property and would be a string of - random bytes. This ID would then be used to scope names. - Starting/locating a service could be done by ID-name pair rather than - only by name. - - - Contrast this with a per-display scope. To achieve that, we would - want a single bus spanning all sessions using a given display. - So we might set a _DBUS_DISPLAY_BUS_ADDRESS - property on screen 0 of the display, pointing to this bus. - - - - - systemd Activation - - - Service description files may contain a - SystemdService key. Its value is the name of a - systemd - service, for example - dbus-com.example.MyDaemon.service. - - - - If this key is present, the bus daemon may carry out activation for - this D-Bus service by sending a request to systemd asking it to - start the systemd service whose name is the value of - SystemdService. For example, the reference - dbus-daemon has a - --systemd-activation option that enables this - feature, and that option is given when it is started by systemd. - - - - On the well-known system bus, it is a common practice to set - SystemdService to dbus-, - followed by the well-known bus name, followed by - .service, then register that name as an alias - for the real systemd service. This allows D-Bus activation of a - service to be enabled or disabled independently of whether the - service is started by systemd during boot. - - - - - Mediating Activation with AppArmor - - - Please refer to - AppArmor documentation - for general information on AppArmor, and how it mediates D-Bus - messages when used in conjunction with a kernel and - dbus-daemon that support this. - - - - In recent versions of the reference dbus-daemon, - AppArmor policy rules of type dbus send - are also used to control auto-starting: if a message is sent to - the well-known name of an activatable service, the - dbus-daemon will attempt to determine whether - it would deliver the message to that service - beforeauto-starting it, by making some - assumptions about the resulting process's credentials. - - - - If it does proceed with auto-starting, when the service appears, the - dbus-daemon repeats the policy check (with - the service's true credentials, which might not be identical) - before delivering the message. In practice, this second check will - usually be more strict than the first; the first check would only - be more strict if there are "blacklist"-style rules like - deny dbus send peer=(label=/usr/bin/protected) - that match on the peer's specific credentials, but AppArmor is - normally used in a "whitelist" style where this does not apply. - - - - To support this process, service description files may contain a - AssumedAppArmorLabel key. Its value is the name - of an AppArmor label, for example - /usr/sbin/mydaemon. - If present, AppArmor mediation of messages that auto-start a - service will decide whether to allow auto-starting to occur based - on the assumption that the activated service will be confined - under the specified label; in particular, rules of the form - dbus send peer=(label=/usr/sbin/mydaemon) or - deny dbus send peer=(label=/usr/sbin/mydaemon) - will match it, allowing or denying as appropriate - (even if there is in fact no profile of that name loaded). - - - - Otherwise, AppArmor mediation of messages that auto-start a - service will decide whether to allow auto-starting to occur - without specifying any particular label. In particular, any rule of - the form dbus send peer=(label=X) or - deny dbus send peer=(label=X) - (for any value of X, including the special label - unconfined) will not influence whether the - auto-start is allowed. - - + Rules of type dbus receive are not checked when deciding whether to allow auto-starting; they are only checked @@ -5429,197 +5038,570 @@ the machine's ID - - the literal character '-' (dash) - + + the literal character '-' (dash) + + + + the X display without the screen number, with the + following prefixes removed, if present: ":", "localhost:" + ."localhost.localdomain:". That is, a display of + "localhost:10.0" produces just the number "10" + + + + + + The contents of this file NAME=value assignment pairs and + lines starting with # are comments (no comments are allowed + otherwise). The following variable names are defined: + + + + + + Variable + + + + meaning + + + + + + DBUS_SESSION_BUS_ADDRESS + + + + the actual address of the server socket + + + + + + DBUS_SESSION_BUS_PID + + + + the PID of the server process + + + + + + DBUS_SESSION_BUS_WINDOWID + + + + the window ID + + + + + + + + + At least the DBUS_SESSION_BUS_ADDRESS variable MUST be present + in this file. + + + + Failure to open this file MUST be interpreted as absence of a + running server. Therefore, the implementation MUST proceed to + attempting to launch a new bus server if the file cannot be + opened. + + + + However, success in opening this file MUST NOT lead to the + conclusion that the server is running. Thus, a failure to connect to + the bus address obtained by the alternative method MUST NOT be + considered a fatal error. If the connection cannot be established, + the implementation MUST proceed to check the X selection settings or + to start the server on its own. + + + + If the implementation concludes that the D-Bus server is not + running it MUST attempt to start a new server and it MUST also + ensure that the daemon started as an effect of the "autolaunch" + mechanism provides the lookup mechanisms described above, so + subsequent calls can locate the newly started server. The + implementation MUST also ensure that if two or more concurrent + initiations happen, only one server remains running and all other + initiations are able to obtain the address of this server and + connect to it. In other words, the implementation MUST ensure that + the X selection is not present when it attempts to set it, without + allowing another process to set the selection between the + verification and the setting (e.g., by using XGrabServer / + XungrabServer). + + + + Finding session services + + On Unix systems, the session bus should search for .service files + in $XDG_DATA_DIRS/dbus-1/services as defined + by the + XDG Base Directory Specification. + Implementations may also search additional locations, + with a higher or lower priority than the XDG directories. + + + As described in the XDG Base Directory Specification, software + packages should install their session .service files to their + configured ${datadir}/dbus-1/services, + where ${datadir} is as defined by the GNU + coding standards. System administrators or users can arrange + for these service files to be read by setting XDG_DATA_DIRS or by + symlinking them into the default locations. + + + + + System message bus + + A computer may have a system message bus, + accessible to all applications on the system. This message bus may be + used to broadcast system events, such as adding new hardware devices, + changes in the printer queue, and so forth. + + + The address of the system message bus is given + in the DBUS_SYSTEM_BUS_ADDRESS environment + variable. If that variable is not set, applications should try + to connect to the well-known address + unix:path=/var/run/dbus/system_bus_socket. + + + The D-Bus reference implementation actually honors the + $(localstatedir) configure option + for this address, on both client and server side. + + + + + On Unix systems, the system bus should default to searching + for .service files in + /usr/local/share/dbus-1/system-services, + /usr/share/dbus-1/system-services and + /lib/dbus-1/system-services, with that order + of precedence. It may also search other implementation-specific + locations, but should not vary these locations based on environment + variables. + + + The system bus is security-sensitive and is typically executed + by an init system with a clean environment. Its launch helper + process is particularly security-sensitive, and specifically + clears its own environment. + + + + + Software packages should install their system .service + files to their configured + ${datadir}/dbus-1/system-services, + where ${datadir} is as defined by the GNU + coding standards. System administrators can arrange + for these service files to be read by editing the system bus' + configuration file or by symlinking them into the default + locations. + + + + + + Message Bus Messages + + The special message bus name org.freedesktop.DBus + responds to a number of additional messages. + + + + <literal>org.freedesktop.DBus.Hello</literal> + + As a method: + + STRING Hello () + + Reply arguments: + + + + + Argument + Type + Description + + + + + 0 + STRING + Unique name assigned to the connection + + + + + + + Before an application is able to send messages to other applications + it must send the org.freedesktop.DBus.Hello message + to the message bus to obtain a unique name. If an application without + a unique name tries to send a message to another application, or a + message to the message bus itself that isn't the + org.freedesktop.DBus.Hello message, it will be + disconnected from the bus. + + + There is no corresponding "disconnect" request; if a client wishes to + disconnect from the bus, it simply closes the socket (or other + communication channel). + + + + <literal>org.freedesktop.DBus.RequestName</literal> + + As a method: + + UINT32 RequestName (in STRING name, in UINT32 flags) + + Message arguments: + + + + + Argument + Type + Description + + + + + 0 + STRING + Name to request + + + 1 + UINT32 + Flags + + + + + Reply arguments: + + + + + Argument + Type + Description + + + + + 0 + UINT32 + Return value + + + + + + + Ask the message bus to assign the given name to the method caller. Each + name maintains a queue of possible owners, where the head of the queue is + the primary or current owner of the name. Each potential owner in the + queue maintains the DBUS_NAME_FLAG_ALLOW_REPLACEMENT and + DBUS_NAME_FLAG_DO_NOT_QUEUE settings from its latest RequestName call. + When RequestName is invoked the following occurs: + + + + If the method caller is currently the primary owner of the name, + the DBUS_NAME_FLAG_ALLOW_REPLACEMENT and DBUS_NAME_FLAG_DO_NOT_QUEUE + values are updated with the values from the new RequestName call, + and nothing further happens. + + + + + + If the current primary owner (head of the queue) has + DBUS_NAME_FLAG_ALLOW_REPLACEMENT set, and the RequestName + invocation has the DBUS_NAME_FLAG_REPLACE_EXISTING flag, then + the caller of RequestName replaces the current primary owner at + the head of the queue and the current primary owner moves to the + second position in the queue. If the caller of RequestName was + in the queue previously its flags are updated with the values from + the new RequestName in addition to moving it to the head of the queue. + + - - the X display without the screen number, with the - following prefixes removed, if present: ":", "localhost:" - ."localhost.localdomain:". That is, a display of - "localhost:10.0" produces just the number "10" - - - + + + If replacement is not possible, and the method caller is + currently in the queue but not the primary owner, its flags are + updated with the values from the new RequestName call. + + - - The contents of this file NAME=value assignment pairs and - lines starting with # are comments (no comments are allowed - otherwise). The following variable names are defined: - - - - - - Variable - + + + If replacement is not possible, and the method caller is + currently not in the queue, the method caller is appended to the + queue. + + - - meaning - - + + + If any connection in the queue has DBUS_NAME_FLAG_DO_NOT_QUEUE + set and is not the primary owner, it is removed from the + queue. This can apply to the previous primary owner (if it + was replaced) or the method caller (if it updated the + DBUS_NAME_FLAG_DO_NOT_QUEUE flag while still stuck in the + queue, or if it was just added to the queue with that flag set). + + + + + + Note that DBUS_NAME_FLAG_REPLACE_EXISTING results in "jumping the + queue," even if another application already in the queue had specified + DBUS_NAME_FLAG_REPLACE_EXISTING. This comes up if a primary owner + that does not allow replacement goes away, and the next primary owner + does allow replacement. In this case, queued items that specified + DBUS_NAME_FLAG_REPLACE_EXISTING do not + automatically replace the new primary owner. In other words, + DBUS_NAME_FLAG_REPLACE_EXISTING is not saved, it is only used at the + time RequestName is called. This is deliberate to avoid an infinite loop + anytime two applications are both DBUS_NAME_FLAG_ALLOW_REPLACEMENT + and DBUS_NAME_FLAG_REPLACE_EXISTING. + + + The flags argument contains any of the following values logically ORed + together: - - - DBUS_SESSION_BUS_ADDRESS - + + + + + Conventional Name + Value + Description + + + + + DBUS_NAME_FLAG_ALLOW_REPLACEMENT + 0x1 + - - the actual address of the server socket - - + If an application A specifies this flag and succeeds in + becoming the owner of the name, and another application B + later calls RequestName with the + DBUS_NAME_FLAG_REPLACE_EXISTING flag, then application A + will lose ownership and receive a + org.freedesktop.DBus.NameLost signal, and + application B will become the new owner. If DBUS_NAME_FLAG_ALLOW_REPLACEMENT + is not specified by application A, or DBUS_NAME_FLAG_REPLACE_EXISTING + is not specified by application B, then application B will not replace + application A as the owner. - - - DBUS_SESSION_BUS_PID - + + + + DBUS_NAME_FLAG_REPLACE_EXISTING + 0x2 + - - the PID of the server process - - + Try to replace the current owner if there is one. If this + flag is not set the application will only become the owner of + the name if there is no current owner. If this flag is set, + the application will replace the current owner if + the current owner specified DBUS_NAME_FLAG_ALLOW_REPLACEMENT. - - - DBUS_SESSION_BUS_WINDOWID - + + + + DBUS_NAME_FLAG_DO_NOT_QUEUE + 0x4 + - - the window ID - - - - - - + Without this flag, if an application requests a name that is + already owned, the application will be placed in a queue to + own the name when the current owner gives it up. If this + flag is given, the application will not be placed in the + queue, the request for the name will simply fail. This flag + also affects behavior when an application is replaced as + name owner; by default the application moves back into the + waiting queue, unless this flag was provided when the application + became the name owner. - - At least the DBUS_SESSION_BUS_ADDRESS variable MUST be present - in this file. - + + + + + - - Failure to open this file MUST be interpreted as absence of a - running server. Therefore, the implementation MUST proceed to - attempting to launch a new bus server if the file cannot be - opened. - + The return code can be one of the following values: - - However, success in opening this file MUST NOT lead to the - conclusion that the server is running. Thus, a failure to connect to - the bus address obtained by the alternative method MUST NOT be - considered a fatal error. If the connection cannot be established, - the implementation MUST proceed to check the X selection settings or - to start the server on its own. - + + + + + Conventional Name + Value + Description + + + + + DBUS_REQUEST_NAME_REPLY_PRIMARY_OWNER + 1 The caller is now the primary owner of + the name, replacing any previous owner. Either the name had no + owner before, or the caller specified + DBUS_NAME_FLAG_REPLACE_EXISTING and the current owner specified + DBUS_NAME_FLAG_ALLOW_REPLACEMENT. + + + DBUS_REQUEST_NAME_REPLY_IN_QUEUE + 2 - - If the implementation concludes that the D-Bus server is not - running it MUST attempt to start a new server and it MUST also - ensure that the daemon started as an effect of the "autolaunch" - mechanism provides the lookup mechanisms described above, so - subsequent calls can locate the newly started server. The - implementation MUST also ensure that if two or more concurrent - initiations happen, only one server remains running and all other - initiations are able to obtain the address of this server and - connect to it. In other words, the implementation MUST ensure that - the X selection is not present when it attempts to set it, without - allowing another process to set the selection between the - verification and the setting (e.g., by using XGrabServer / - XungrabServer). - - - - Finding session services - - On Unix systems, the session bus should search for .service files - in $XDG_DATA_DIRS/dbus-1/services as defined - by the - XDG Base Directory Specification. - Implementations may also search additional locations, - with a higher or lower priority than the XDG directories. - - - As described in the XDG Base Directory Specification, software - packages should install their session .service files to their - configured ${datadir}/dbus-1/services, - where ${datadir} is as defined by the GNU - coding standards. System administrators or users can arrange - for these service files to be read by setting XDG_DATA_DIRS or by - symlinking them into the default locations. - - - - - System message bus - - A computer may have a system message bus, - accessible to all applications on the system. This message bus may be - used to broadcast system events, such as adding new hardware devices, - changes in the printer queue, and so forth. - - - The address of the system message bus is given - in the DBUS_SYSTEM_BUS_ADDRESS environment - variable. If that variable is not set, applications should try - to connect to the well-known address - unix:path=/var/run/dbus/system_bus_socket. - - - The D-Bus reference implementation actually honors the - $(localstatedir) configure option - for this address, on both client and server side. - - + The name already had an owner, + DBUS_NAME_FLAG_DO_NOT_QUEUE was not specified, and either + the current owner did not specify + DBUS_NAME_FLAG_ALLOW_REPLACEMENT or the requesting + application did not specify DBUS_NAME_FLAG_REPLACE_EXISTING. + + + + DBUS_REQUEST_NAME_REPLY_EXISTS 3 + The name already has an owner, + DBUS_NAME_FLAG_DO_NOT_QUEUE was specified, and either + DBUS_NAME_FLAG_ALLOW_REPLACEMENT was not specified by the + current owner, or DBUS_NAME_FLAG_REPLACE_EXISTING was not + specified by the requesting application. + + + DBUS_REQUEST_NAME_REPLY_ALREADY_OWNER + 4 + The application trying to request ownership of a name is already the owner of it. + + + + + + + + <literal>org.freedesktop.DBus.ReleaseName</literal> - On Unix systems, the system bus should default to searching - for .service files in - /usr/local/share/dbus-1/system-services, - /usr/share/dbus-1/system-services and - /lib/dbus-1/system-services, with that order - of precedence. It may also search other implementation-specific - locations, but should not vary these locations based on environment - variables. - - - The system bus is security-sensitive and is typically executed - by an init system with a clean environment. Its launch helper - process is particularly security-sensitive, and specifically - clears its own environment. - - + As a method: + + UINT32 ReleaseName (in STRING name) + + Message arguments: + + + + + Argument + Type + Description + + + + + 0 + STRING + Name to release + + + + + Reply arguments: + + + + + Argument + Type + Description + + + + + 0 + UINT32 + Return value + + + + - Software packages should install their system .service - files to their configured - ${datadir}/dbus-1/system-services, - where ${datadir} is as defined by the GNU - coding standards. System administrators can arrange - for these service files to be read by editing the system bus' - configuration file or by symlinking them into the default - locations. - - - + Ask the message bus to release the method caller's claim to the given + name. If the caller is the primary owner, a new primary owner will be + selected from the queue if any other owners are waiting. If the + caller is waiting in the queue for the name, the caller will removed + from the queue and will not be made an owner of the name if it later + becomes available. If there are no other owners in the queue for the + name, it will be removed from the bus entirely. - - Message Bus Messages - - The special message bus name org.freedesktop.DBus - responds to a number of additional messages. - + The return code can be one of the following values: - - <literal>org.freedesktop.DBus.Hello</literal> + + + + + Conventional Name + Value + Description + + + + + DBUS_RELEASE_NAME_REPLY_RELEASED + 1 The caller has released his claim on + the given name. Either the caller was the primary owner of + the name, and the name is now unused or taken by somebody + waiting in the queue for the name, or the caller was waiting + in the queue for the name and has now been removed from the + queue. + + + DBUS_RELEASE_NAME_REPLY_NON_EXISTENT + 2 + The given name does not exist on this bus. + + + DBUS_RELEASE_NAME_REPLY_NOT_OWNER + 3 + The caller was not the primary owner of this name, + and was also not waiting in the queue to own this name. + + + + + + + + + <literal>org.freedesktop.DBus.ListQueuedOwners</literal> As a method: - STRING Hello () + ARRAY of STRING ListQueuedOwners (in STRING name) - Reply arguments: + Message arguments: @@ -5633,25 +5615,36 @@ 0 STRING - Unique name assigned to the connection + The well-known bus name to query, such as + com.example.cappuccino + + + + + Reply arguments: + + + + + Argument + Type + Description + + + + + 0 + ARRAY of STRING + The unique bus names of connections currently queued + for the name - Before an application is able to send messages to other applications - it must send the org.freedesktop.DBus.Hello message - to the message bus to obtain a unique name. If an application without - a unique name tries to send a message to another application, or a - message to the message bus itself that isn't the - org.freedesktop.DBus.Hello message, it will be - disconnected from the bus. - - - There is no corresponding "disconnect" request; if a client wishes to - disconnect from the bus, it simply closes the socket (or other - communication channel). + List the connections currently queued for a bus name (see + ). -- 2.12.2