Dbus service description file

In send. New code should use GDBus instead. Sub-par article, the code was hard to read because there is no indentation used. You only lightly touch the surface of DBus.

What I would've liked to see is an in-depth explanation on how to register a program to a specific bus and register what interfaces it will be using. Also; this tutorial is outdated, but the title is very misleading. It made me think there was relevant information here. It might have been relevant to some people but not to me! I appreciate you trying to write a guide though!

Does anyone know whether Dbus has a port on Windows 7? Also Any idea about what is Dbus-Glibc? It is still working. If you prefer gdbus, then use that.

Thanks for the comments. This mutex will be inspected by the dbus client library to detect a running dbus session bus. The access to the mutex and the shared memory section are protected by global locks. In the recent implementation the autolaunch transport uses a tcp transport on localhost with a port choosen from the operating system.

This detail may change in the future. Because of this the implementation is not documentated yet. A working D-Bus implementation uses universally-unique IDs in two places. Second, each operating system kernel instance running a D-Bus client or server has a UUID identifying that kernel, retrieved by invoking the method org. The term "UUID" in this document is intended literally, i. The UUID must contain bits of data and be hex-encoded. The hex-encoded string may not contain hyphens or other non-hex-digit characters, and it must be exactly 32 characters long.

To generate a UUID, the current reference implementation concatenates 96 bits of random data followed by the bit time in seconds since the UNIX epoch in big endian byte order. It would also be acceptable and probably better to simply generate bits of random data, as long as the random number generator is of high quality. The timestamp could conceivably help if the random bits are not very random. With a quality random number generator, collisions are extremely unlikely even with only 96 bits, so it's somewhat academic.

Implementations should, however, stick to random data for the first 96 bits of the UUID. There are some standard interfaces that may be useful across various D-Bus applications. The org. Peer interface has two methods:. It does not matter which object path a ping is sent to. The reference implementation handles this method automatically.

This UUID must be the same for all processes on a single system at least until that system next reboots. It should be the same across reboots if possible, but this is not always possible to implement and is not guaranteed. It does not matter which object path a GetMachineId is sent to. The latter is defined by systemd , but systems not using systemd may provide an equivalent file. This can be obtained with the GetCurrentHwProfile function.

The UUID is intended to be per-instance-of-the-operating-system, so may represent a virtual machine running on a hypervisor, rather than a physical machine. The UUID is often used where other programs might use a hostname. Hostnames can change without rebooting, however, or just be "localhost" - so the UUID is more robust. Objects instances may implement Introspect which returns an XML description of the object, including its interfaces with signals and methods , objects below it in the object path tree, and its properties.

Many native APIs will have a concept of object properties or attributes. These can be exposed via the org. Properties interface. It is conventional to give D-Bus properties names consisting of capitalized words without punctuation "CamelCase" , like member names.

Strictly speaking, D-Bus property names are not required to follow the same naming restrictions as member names, but D-Bus property names that would not be valid member names in particular, GObject-style dash-separated property names can cause interoperability problems and should be avoided.

The available properties and whether they are writable can be determined by calling org. An empty string may be provided for the interface name; in this case, if there are multiple properties on an object with the same name, the results are undefined picking one by according to an arbitrary deterministic rule, or returning an error, are the reasonable possibilities.

If org. GetAll is called with a valid interface name which contains no properties, an empty array should be returned. If it is called with a valid interface name for which some properties are not accessible to the caller for example, due to per-property access control implemented in the service , those properties should be silently omitted from the result array.

Get is called for any such properties, an appropriate access control error should be returned. If one or more properties change on an object, the org. PropertiesChanged signal may be emitted this signal was added in 0. Whether the PropertiesChanged signal is supported can be determined by calling org.

Note that the signal may be supported for an object but it may differ how whether and how it is used on a per-property basis for e.

Each property or the parent interface must be annotated with the org. EmitsChangedSignal annotation to convey this usually the default value true is sufficient meaning that the annotation does not need to be used. An API can optionally make use of this interface for one or more sub-trees of objects.

The root of each sub-tree implements this interface so other applications can get all objects, interfaces and properties in a single method call.

It is appropriate to use this interface if users of the tree of objects are expected to be interested in all interfaces of all objects in the tree; a more granular API should be used if users of the objects are expected to be interested in a small subset of the objects, a small subset of their interfaces, or both. The method that applications can use to get all objects and properties is GetManagedObjects :.

The return value of this method is a dict whose keys are object paths. All returned object paths are children of the object path implementing this interface, i.

Each value is a dict whose keys are interfaces names. Each value in this inner dict is the same dict that would be returned by the org. GetAll method for that combination of object path and interface. If an interface has no properties, the empty dict is returned.

The InterfacesAdded signal is emitted when either a new object is added or when an existing object gains one or more interfaces. The InterfacesRemoved signal is emitted whenever an object is removed or it loses one or more interfaces. The second parameter of the InterfacesAdded signal contains a dict with the interfaces and properties if any that have been added to the given object path. Similarly, the second parameter of the InterfacesRemoved signal contains an array of the interfaces that were removed.

Note that changes on properties on existing interfaces are not reported using this interface - an application should also monitor the existing PropertiesChanged signal on each object. Applications SHOULD NOT export objects that are children of an object directly or otherwise implementing this interface but which are not returned in the reply from the GetManagedObjects method of this interface on the given object. The intent of the ObjectManager interface is to make it easy to write a robust client implementation.

The trivial client implementation only needs to make two method calls:. Whenever a new remote object is created or an existing object gains a new interface , the InterfacesAdded signal is emitted, and since this signal contains all properties for the interfaces, no calls to the org.

Properties interface on the remote object are needed. Additionally, since the initial AddMatch rule already includes signal messages from the newly created child object, no new AddMatch call is needed. ObjectManager interface was added in version 0. The same XML format may be used in other contexts as well, for example as an "IDL" for generating static language bindings. The intent is that if an object knows that its children are "fast" to introspect it can go ahead and return their information, but otherwise it can omit it.

Signals only allow "out" so while direction may be specified, it's pointless. They are similar conceptually to Java's annotations and C attributes. Well-known annotations:. If set to false , the org.

If set to const the property never changes value during the lifetime of the object it belongs to, and hence the signal is never emitted for it. If set to invalidates the signal is emitted but the value is not included in the signal.

If set to true the signal is emitted with the value included. The value for the annotation defaults to true if the enclosing interface element does not specify the annotation. Otherwise it defaults to the value specified in the enclosing interface element. This annotation is intended to be used by code generators to implement client-side caching of property values.

For all properties for which the annotation is set to const , invalidates or true the client may unconditionally cache the values as the properties don't change or notifications are generated for them if they do.

The message bus accepts connections from one or more applications. Once connected, applications can exchange messages with other applications that are also connected to the bus. In order to route messages among connections, the message bus keeps a mapping from names to connections. Each connection has one unique-for-the-lifetime-of-the-bus name automatically assigned. Applications may request additional names for a connection.

Additional names are usually "well-known names" such as "com. When a name is bound to a connection, that connection is said to own the name. The bus itself owns a special name, org. DBus interface. This service allows applications to make administrative requests of the bus itself. For example, applications can ask the bus to assign a name to a connection. Each name may have queued owners. When an application requests a name for a connection and the name is already in use, the bus will optionally add the connection to a queue waiting for the name.

If the current owner of the name disconnects or releases the name, the next connection in the queue will become the new owner. This feature causes the right thing to happen if you start two text editors for example; the first one may request "com.

TextEditor1", and the second will be queued as a possible owner of that name. When the first exits, the second will take over. Applications may send unicast messages to a specific recipient or to the message bus itself, or broadcast messages to all interested recipients. Each connection has at least one name, assigned at connection time and returned in response to the org. Hello method call.

This automatically-assigned name is called the connection's unique name. Unique names are never reused for two different connections to the same bus. Ownership of a unique name is a prerequisite for interaction with the message bus. It logically follows that the unique name is always the first name that an application comes to own, and the last one that it loses ownership of. Unique connection names must begin with the character ':' ASCII colon character ; bus names that are not unique names must not begin with this character.

The bus must reject any attempt by an application to manually request a name beginning with ':'. This restriction categorically prevents "spoofing"; messages sent to a unique name will always go to the expected connection.

When a connection is closed, all the names that it owns are deleted or transferred to the next connection in the queue if any. A connection can request additional names to be associated with it using the org.

RequestName message. These names can be released again using the org. ReleaseName message. Method calls and replies normally specify this field. Most signal messages are broadcasts, and no other message types currently defined in this specification may be broadcast.

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.

For example, sending an org. Continuing the org. 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.

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 interacts poorly with buses with non-trivial access control restrictions, and is deprecated. 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. 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.

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. As a result, match rules are mainly used to receive a subset of broadcast signals.

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. The following table describes the keys that can be used to create a match rule. 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. This match key was added in version 0. Argument path matches provide a specialised form of wildcard matching for path-like namespaces.

As with normal argument matches, if the argument is exactly equal to the string given in the match rule then the rule is satisfied. 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. Since D-Bus 1. 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. 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.

In either case, this implies a contract documented along with the name com. 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. Service description files have the ". The message bus will only load service description files ending with.

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. 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.

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.

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. 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. On the well-known session bus, if two. Distributors should avoid this situation, for instance by naming session services'. If two. The currently-defined values for this variable are system for the systemwide message bus, and session for the per-login-session message bus. 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.

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. This ID would then be used to scope names. Contrast this with a per-display scope. To achieve that, we would want a single bus spanning all sessions using a given display. Service description files may contain a SystemdService key. Its value is the name of a systemd service, for example dbus-com.

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.

This allows D-Bus activation of a service to be enabled or disabled independently of whether the service is started by systemd during boot. 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 before auto-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.

To support this process, service description files may contain a AssumedAppArmorLabel key. Otherwise, AppArmor mediation of messages that auto-start a service will decide whether to allow auto-starting to occur without specifying any particular label.

Rules of type dbus receive are not checked when deciding whether to allow auto-starting; they are only checked against the service's profile after the service has started, when deciding whether to deliver the message that caused the auto-starting operation. Two standard message bus instances are defined here, along with how to locate them and where their service files live. Each time a user logs in, a login session message bus may be started.

All applications in the user's login session may interact with one another using this message bus. The environment variable should have precedence over the root window property. Note that this mechanism is not recommended for attempting to determine if a daemon is running.

It is inherently racy to attempt to make this determination, since the bus daemon may be started just before or just after the determination is made. Therefore, it is recommended that applications do not try to make this determination for their functionality purposes, and instead they should attempt to start the server.

For the X Windowing System, the application must locate the window owner of the selection represented by the atom formed by concatenating:. The following properties are defined for the window that owns this X selection:. If the X selection cannot be located or if reading the properties from the window fails, the implementation MUST conclude that there is no D-Bus server running and proceed to start a new server. See below on concurrency issues. Failure to connect to the D-Bus server address thus obtained MUST be treated as a fatal connection error and should be reported to the application.

As an alternative, an implementation MAY find the information in the following file located in the current user's home directory, in subdirectory. That is, a display of "localhost The following variable names are defined:. 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. 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. On Unix systems, the session bus should search for. Implementations may also search additional locations, with a higher or lower priority than the XDG directories.

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. On Unix systems, the system bus should default to searching for. It may also search other implementation-specific locations, but should not vary these locations based on environment variables. Software packages should install their system.

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. The special message bus name org. For historical reasons, some of the methods in the org. DBus interface are available on multiple object paths. Message bus implementations should accept method calls that were added before specification version 0.

Message bus implementations should not accept newer method calls on unexpected object paths, and as a security hardening measure, older method calls that are security-sensitive may be rejected with the error org.

AccessDenied when called on an unexpected object path. Support for the Properties and Peer interfaces was added in version 1. Before an application is able to send messages to other applications it must send the org. 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. 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. 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. When RequestName is invoked the following occurs:. 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. This comes up if a primary owner that does not allow replacement goes away, and the next primary owner does allow replacement. The flags argument contains any of the following values logically ORed together:.

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. The return code can be one of the following values:. List the connections currently queued for a bus name see Queued Name Owner.

This signal indicates that the owner of a name has changed. It's also the signal to use to detect the appearance of new names on the bus. This signal is sent to a specific application when it loses ownership of a name. This signal is sent to a specific application when it gains ownership of a name. Tries to launch the executable associated with a name service activation , as an explicit request. This is an alternative to relying on auto-starting. It is often preferable to carry out auto-starting instead of calling this method.

As a result, calling this method does not remove the need for the caller to handle errors from method calls. Given that fact, it is usually simpler to rely on auto-starting, in which the required service starts as a side-effect of the first method call.

Normally, session bus activated services inherit the environment of the bus daemon. This method adds to or modifies that environment when activating services. Some bus instances, such as the standard system bus, may disable access to this method for some or all callers. Note, both the environment variable names and values must be valid UTF There's no way to update the activation environment with data that is invalid UTF Returns the unique connection name of the primary owner of the name given.

If the requested name doesn't have an owner, returns a org. NameHasNoOwner error. Returns the Unix user ID of the process connected to the server. If unable to determine it for instance, because the process is not on the same machine as the bus daemon , an error is returned.

Returns the Unix process ID of the process connected to the server. Returns as many credentials as possible for the process connected to the server. If unable to determine certain credentials for instance, because the process is not on the same machine as the bus daemon, or because this version of the bus daemon does not support a particular security framework , or if the values of those credentials cannot be represented as documented here, then those credentials are omitted.

Keys in the returned dictionary not containing ". Bus daemon implementors supporting credentials frameworks not mentioned in this document should either contribute patches to this specification, or use keys containing ". The array contains the non-zero bytes of the security label in an unspecified ASCII-compatible encoding [a] , followed by a single zero byte.

On Smack systems, this is the Smack label. On AppArmor systems, this is the AppArmor context, a composite string encoding the AppArmor label one or more profiles and the enforcement mode. Always appending the zero byte allows callers to read the string from the message payload without copying.

This method was added in D-Bus 1. Returns auditing data used by Solaris ADT, in an unspecified binary format. If you know what this means, please contribute documentation via the D-Bus bug tracking system. Returns the security context used by SELinux, in an unspecified format. If the bus does not have enough resources the org. OOM error is returned. If the rule is not found the org. MatchRuleNotFound error is returned. Gets the unique ID of the bus.

The per-bus and per-address IDs are not related. For a desktop session bus, the bus ID can be used as a way to uniquely identify a user's session. Only a user who is privileged on this bus by some implementation-specific definition may create monitor connections [5]. Monitor connections lose all their bus names, including the unique connection name, and all their match rules.

Sending messages on a monitor connection is not allowed: applications should use a private connection for monitoring. Monitor connections may receive all messages, even messages that should only have gone to some other connection "eavesdropping". The first argument is a list of match rules, which replace any match rules that were previously active for this connection. As a special case, an empty list of match rules which would otherwise match nothing, making the monitor useless is treated as a shorthand for matching all messages.

The second argument might be used for flags to influence the behaviour of the monitor connection in future D-Bus versions. Message bus implementations should attempt to minimize the side-effects of monitoring — in particular, unlike ordinary eavesdropping, monitoring the system bus does not require the access control rules to be relaxed, which would change the set of messages that can be delivered to their non-monitor destinations. However, it is unavoidable that monitoring will increase the message bus's resource consumption.

In edge cases where there was barely enough time or memory without monitoring, this might result in message deliveries failing when they would otherwise have succeeded. This property was added in version 1. This message bus filters messages via the AppArmor security framework. This feature should only be advertised if AppArmor mediation is enabled and active at runtime; merely compiling in support for AppArmor should not result in this feature being advertised on message bus instances where it is disabled by message bus or operating system configuration.

This message bus guarantees that it will remove header fields that it does not understand when it relays messages, so that a client receiving a recently-defined header field that is specified to be controlled by the message bus can safely assume that it was in fact set by the message bus. This check is needed because older message bus implementations did not guarantee to filter headers in this way, so a malicious client could send any recently-defined header field with a crafted value of its choice through an older message bus that did not understand that header field.

This message bus filters messages via the SELinux security framework. Similar to apparmor , this feature should only be advertised if SELinux mediation is enabled and active at runtime if SELinux is placed in permissive mode, that is still considered to be active.

When asked to activate a service that has the SystemdService field in its. Unlike the standard Introspectable interface, querying this property does not require parsing XML. The standard org. DBus and org. Properties interfaces are not included in the value of this property, because their presence can be inferred from the fact that a method call on org. Properties asking for properties of org. DBus was successful. Peer and org. Introspectable interfaces are not included in the value of this property either, because they do not indicate features of the message bus implementation.

The message bus maintains an association between names and connections. Print the address of the message bus to standard output, or to the given file descriptor. This is used by programs that launch the message bus. Print the process ID of the message bus to standard output, or to the given file descriptor. Set the address to listen on. See the documentation of that directive for more details.

Enable systemd-style service activation. Only useful in conjunction with the systemd system and session manager on Linux. Force the message bus to use the system log for messages, in addition to writing to standard error, even if the configuration file does not specify that it should. Force the message bus to use the system log for messages, and not duplicate them to standard error. Force the message bus to use only standard error for messages, even if the configuration file specifies that it should use the system log.

With this option, the dbus daemon raises an event when it is ready to process connections. The parent process must create this event object for example with the CreateEvent function in a nonsignaled state, then configure it to be inherited by the dbus-daemon process.

The dbus-daemon will signal the event as if via SetEvent when it is ready to receive connections from clients. The parent process can wait for this to occur by using functions such as WaitForSingleObject. This option is only supported under Windows.

A message bus daemon has a configuration file that specializes it for a particular application. For example, one configuration file might set up the message bus to be a systemwide message bus, while another might set it up to be a per-user-login-session bus. The configuration file is not part of any interoperability specification and its backward compatibility is not guaranteed; this document is documentation, not specification.

Third-party packages should install the default policies necessary for correct operation into that directory, which has been supported since dbus 1. The well-known type of the message bus.

Currently known values are "system" and "session"; if other values are set, they should be either added to the D-Bus specification, or namespaced. This element only controls which message bus specific environment variables are set in activated clients. Most of the policy that distinguishes a session bus from the system bus is controlled from the other elements in the configuration file. If the filename is relative, it is located relative to the configuration file doing the including. This attribute controls whether it's a fatal error for the included file to be absent.

Files in the directory are included in undefined order. Only files ending in ". This is intended to allow extension of the system bus by particular packages. The user account the daemon should run as, as either a username or a UID. If the daemon cannot change to this UID on startup, it will exit. If this element is not present, the daemon will not change or care about its UID.

The user is changed after the bus has completed initialization. So sockets etc. This means that sockets and PID files can be created in a location that requires root privileges for writing. If present, the bus daemon becomes a real daemon forks into the background, etc. This is generally used rather than the --fork command line option.

If present, the bus daemon keeps its original umask when forking. This may be useful to avoid affecting the behavior of child processes. If present, the bus daemon will log to syslog. The --syslog, --syslog-only and --nosyslog command-line options take precedence over this setting.

If present, the bus daemon will write its pid to the specified file. The --nopidfile command-line option takes precedence over this setting. Using this directive in the configuration of the well-known system bus or the well-known session bus will make that bus insecure and should never be done.

Similarly, on custom bus types, using this directive will usually make the custom bus insecure, unless its configuration has been specifically designed to prevent anonymous users from causing damage or escalating privileges.

Add an address that the bus should listen on. On platforms other than Windows, unix -based transports unix , systemd , launchd are the default for both the well-known system bus and the well-known session bus, and are strongly recommended. On Windows, unix -based transports are not available, so TCP-based transports must be used. In particular, configuring the well-known system bus or the well-known session bus to listen on a non-loopback TCP address is insecure. Developers are sometimes tempted to use remote TCP as a debugging tool.

However, if this functionality is left enabled in finished products, the result will be dangerously insecure. Instead of using remote TCP, developers should relay connections via Secure Shell or a similar protocol. Remote TCP connections were historically sometimes used to share a single session bus between login sessions of the same user on different machines within a trusted local area network, in conjunction with unencrypted remote X11, a NFS-shared home directory and NIS YP authentication.

The D-Bus maintainers recommend using a separate session bus per user, machine pair, only accessible from within that machine. If a hostname resolves to multiple addresses, the server will bind to all of them. A special case is using a port number of zero or omitting the port , which means to choose an available port selected by the operating system. If not specified, the default is the same value as "host". Lists permitted authorization mechanisms.

If this element doesn't exist, then all known mechanisms are allowed. The order in which mechanisms are listed is not meaningful.