From 856e9e3141a76e2cdfea5776bfe08e8311f50d16 Mon Sep 17 00:00:00 2001 From: Ralf Habacker Date: Tue, 5 Feb 2013 01:20:46 +0100 Subject: [PATCH] Moved docbook sources used by cmake into doc subdir and adapted cmake build system. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=59805 --- cmake/bus/dbus-daemon.xml | 752 ----------------------------------- cmake/doc/CMakeLists.txt | 9 +- cmake/tools/dbus-launch.xml | 240 ------------ cmake/tools/dbus-monitor.xml | 121 ------ cmake/tools/dbus-send.xml | 143 ------- doc/dbus-daemon.1.xml.in | 888 ++++++++++++++++++++++++++++++++++++++++++ doc/dbus-daemon.xml.in | 752 +++++++++++++++++++++++++++++++++++ doc/dbus-launch.1.xml | 270 +++++++++++++ doc/dbus-launch.xml | 240 ++++++++++++ doc/dbus-monitor.1.xml | 121 ++++++ doc/dbus-monitor.xml | 121 ++++++ doc/dbus-send.1.xml | 157 ++++++++ doc/dbus-send.xml | 143 +++++++ doc/dbus-uuidgen.1.xml | 125 ++++++ 14 Dateien geändert, 2822 Zeilen hinzugefügt(+), 1260 Zeilen entfernt(-) delete mode 100644 cmake/bus/dbus-daemon.xml delete mode 100644 cmake/tools/dbus-launch.xml delete mode 100644 cmake/tools/dbus-monitor.xml delete mode 100644 cmake/tools/dbus-send.xml create mode 100644 doc/dbus-daemon.1.xml.in create mode 100644 doc/dbus-daemon.xml.in create mode 100644 doc/dbus-launch.1.xml create mode 100644 doc/dbus-launch.xml create mode 100644 doc/dbus-monitor.1.xml create mode 100644 doc/dbus-monitor.xml create mode 100644 doc/dbus-send.1.xml create mode 100644 doc/dbus-send.xml create mode 100644 doc/dbus-uuidgen.1.xml diff --git a/cmake/bus/dbus-daemon.xml b/cmake/bus/dbus-daemon.xml deleted file mode 100644 index f331699..0000000 --- a/cmake/bus/dbus-daemon.xml +++ /dev/null @@ -1,752 +0,0 @@ - - - - - - - - - -dbus-daemon -1 - - -dbus-daemon -Message bus daemon - - - - - dbus-daemon - - dbus-daemon --version - --session - --system - --config-file=FILE - --print-address =DESCRIPTOR - --print-pid =DESCRIPTOR - --fork - - - - - -DESCRIPTION -dbus-daemon is the D-Bus message bus daemon. See -http://www.freedesktop.org/software/dbus/ for more information about -the big picture. D-Bus is first a library that provides one-to-one -communication between any two applications; dbus-daemon is an -application that uses this library to implement a message bus -daemon. Multiple programs connect to the message bus daemon and can -exchange messages with one another. - - -There are two standard message bus instances: the systemwide message bus -(installed on many systems as the "messagebus" init service) and the -per-user-login-session message bus (started each time a user logs in). -dbus-daemon is used for both of these instances, but with -a different configuration file. - - -The --session option is equivalent to -"--config-file=/etc/dbus-1/session.conf" and the --system -option is equivalent to -"--config-file=/etc/dbus-1/system.conf". By creating -additional configuration files and using the --config-file option, -additional special-purpose message bus daemons could be created. - - -The systemwide daemon is normally launched by an init script, -standardly called simply "messagebus". - - -The systemwide daemon is largely used for broadcasting system events, -such as changes to the printer queue, or adding/removing devices. - - -The per-session daemon is used for various interprocess communication -among desktop applications (however, it is not tied to X or the GUI -in any way). - - -SIGHUP will cause the D-Bus daemon to PARTIALLY reload its -configuration file and to flush its user/group information caches. Some -configuration changes would require kicking all apps off the bus; so they will -only take effect if you restart the daemon. Policy changes should take effect -with SIGHUP. - - - -OPTIONS -The following options are supported: - - - - -Use the given configuration file. - - - - - -Force the message bus to fork and become a daemon, even if -the configuration file does not specify that it should. -In most contexts the configuration file already gets this -right, though. - - - - - -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. This is used by programs that -launch the message bus. - - - - - -Use the standard configuration file for the per-login-session message -bus. - - - - - -Use the standard configuration file for the systemwide message bus. - - - - - -Print the version of the daemon. - - - - - - -CONFIGURATION FILE -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 also establishes resource limits, security -parameters, and so forth. - - -The configuration file is not part of any interoperability -specification and its backward compatibility is not guaranteed; this -document is documentation, not specification. - - -The standard systemwide and per-session message bus setups are -configured in the files "/etc/dbus-1/system.conf" and -"/etc/dbus-1/session.conf". These files normally -<include> a system-local.conf or session-local.conf; you can put local -overrides in those files to avoid modifying the primary configuration -files. - - -The configuration file is an XML document. It must have the following -doctype declaration: - - - <!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-Bus Bus Configuration 1.0//EN" - "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd"> - - - - -The following elements may be present in the configuration file. - - - - <busconfig> - - - - - - -Root element. - - - - <type> - - - - - - - -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. The last -<type> element "wins" (previous values are ignored). - - -Example: <type>session</type> - - - - <include> - - - - - - -Include a file <include>filename.conf</include> at this point. If the -filename is relative, it is located relative to the configuration file -doing the including. - - -<include> has an optional attribute "ignore_missing=(yes|no)" -which defaults to "no" if not provided. This attribute -controls whether it's a fatal error for the included file -to be absent. - - - - <includedir> - - - - - - - -Include all files in <includedir>foo.d</includedir> at this -point. Files in the directory are included in undefined order. -Only files ending in ".conf" are included. - - -This is intended to allow extension of the system bus by particular -packages. For example, if CUPS wants to be able to send out -notification of printer queue changes, it could install a file to -/etc/dbus-1/system.d that allowed all apps to receive -this message and allowed the printer daemon user to send it. - - - - <user> - - - - - - - -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 last <user> entry in the file "wins", the others are ignored. - - -The user is changed after the bus has completed initialization. So -sockets etc. will be created before changing user, but no data will be -read from clients before changing user. This means that sockets -and PID files can be created in a location that requires root -privileges for writing. - - - - <fork> - - - - - - -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. - - - - <listen> - - - - - - - -Add an address that the bus should listen on. The -address is in the standard D-Bus format that contains -a transport name plus possible parameters/options. - - -Example: <listen>unix:path=/tmp/foo</listen> - - -If there are multiple <listen> elements, then the bus listens -on multiple addresses. The bus will pass its address to -started services or other interested parties with -the last address given in <listen> first. That is, -apps will try to connect to the last <listen> address first. - - - - <auth> - - - - - - - -Lists permitted authorization mechanisms. If this element doesn't -exist, then all known mechanisms are allowed. If there are multiple -<auth> elements, all the listed mechanisms are allowed. The order in -which mechanisms are listed is not meaningful. - - -Example: <auth>EXTERNAL</auth> - - -Example: <auth>DBUS_COOKIE_SHA1</auth> - - - - <servicedir> - - - - - - - -Adds a directory to scan for .service files. Directories are -scanned starting with the last to appear in the config file -(the first .service file found that provides a particular -service will be used). - - -Service files tell the bus how to automatically start a program. -They are primarily used with the per-user-session bus, -not the systemwide bus. - - - - <standard_session_servicedirs/> - - - - - - - -<standard_session_servicedirs/> is equivalent to specifying a series -of <servicedir/> elements for each of the data directories in the "XDG -Base Directory Specification" with the subdirectory "dbus-1/services", -so for example "/usr/share/dbus-1/services" would be among the -directories searched. - - -The "XDG Base Directory Specification" can be found at -http://freedesktop.org/wiki/Standards/basedir-spec if it hasn't moved, -otherwise try your favorite search engine. - - -The <standard_session_servicedirs/> option is only relevant to the -per-user-session bus daemon defined in -/etc/dbus-1/session.conf. Putting it in any other -configuration file would probably be nonsense. - - - - <limit> - - - - - - - -<limit> establishes a resource limit. For example: - - <limit name="max_message_size">64</limit> - <limit name="max_completed_connections">512</limit> - - - -The name attribute is mandatory. -Available limit names are: - - "max_incoming_bytes" : total size in bytes of messages - incoming from a single connection - "max_outgoing_bytes" : total size in bytes of messages - queued up for a single connection - "max_message_size" : max size of a single message in - bytes - "service_start_timeout" : milliseconds (thousandths) until - a started service has to connect - "auth_timeout" : milliseconds (thousandths) a - connection is given to - authenticate - "max_completed_connections" : max number of authenticated connections - "max_incomplete_connections" : max number of unauthenticated - connections - "max_connections_per_user" : max number of completed connections from - the same user - "max_pending_service_starts" : max number of service launches in - progress at the same time - "max_names_per_connection" : max number of names a single - connection can own - "max_match_rules_per_connection": max number of match rules for a single - connection - "max_replies_per_connection" : max number of pending method - replies per connection - (number of calls-in-progress) - "reply_timeout" : milliseconds (thousandths) - until a method call times out - - - -The max incoming/outgoing queue sizes allow a new message to be queued -if one byte remains below the max. So you can in fact exceed the max -by max_message_size. - - -max_completed_connections divided by max_connections_per_user is the -number of users that can work together to denial-of-service all other users by using -up all connections on the systemwide bus. - - -Limits are normally only of interest on the systemwide bus, not the user session -buses. - - - - <policy> - - - - - - - -The <policy> element defines a security policy to be applied to a particular -set of connections to the bus. A policy is made up of -<allow> and <deny> elements. Policies are normally used with the systemwide bus; -they are analogous to a firewall in that they allow expected traffic -and prevent unexpected traffic. - - -The <policy> element has one of three attributes: - - context="(default|mandatory)" - user="username or userid" - group="group name or gid" - - - - -Policies are applied to a connection as follows: - - - all context="default" policies are applied - - all group="connection's user's group" policies are applied - in undefined order - - all user="connection's auth user" policies are applied - in undefined order - - all context="mandatory" policies are applied - - - -Policies applied later will override those applied earlier, -when the policies overlap. Multiple policies with the same -user/group/context are applied in the order they appear -in the config file. - - - - <deny> - -<allow> - - - - - -A <deny> element appears below a <policy> element and prohibits some -action. The <allow> element makes an exception to previous <deny> -statements, and works just like <deny> but with the inverse meaning. - - -The possible attributes of these elements are: - - send_interface="interface_name" - send_member="method_or_signal_name" - send_error="error_name" - send_destination="name" - send_type="method_call" | "method_return" | "signal" | "error" - send_path="/path/name" - - receive_interface="interface_name" - receive_member="method_or_signal_name" - receive_error="error_name" - receive_sender="name" - receive_type="method_call" | "method_return" | "signal" | "error" - receive_path="/path/name" - - send_requested_reply="true" | "false" - receive_requested_reply="true" | "false" - - eavesdrop="true" | "false" - - own="name" - own_prefix="name" - user="username" - group="groupname" - - - -Examples: - - <deny send_interface="org.freedesktop.System" send_member="Reboot"/> - <deny receive_interface="org.freedesktop.System" receive_member="Reboot"/> - <deny own="org.freedesktop.System"/> - <deny send_destination="org.freedesktop.System"/> - <deny receive_sender="org.freedesktop.System"/> - <deny user="john"/> - <deny group="enemies"/> - - - -The <deny> element's attributes determine whether the deny "matches" a -particular action. If it matches, the action is denied (unless later -rules in the config file allow it). - - -send_destination and receive_sender rules mean that messages may not be -sent to or received from the *owner* of the given name, not that -they may not be sent *to that name*. That is, if a connection -owns services A, B, C, and sending to A is denied, sending to B or C -will not work either. - - -The other send_* and receive_* attributes are purely textual/by-value -matches against the given field in the message header. - - -"Eavesdropping" occurs when an application receives a message that -was explicitly addressed to a name the application does not own. -Eavesdropping thus only applies to messages that are addressed to -services (i.e. it does not apply to signals). - - -For <allow>, eavesdrop="true" indicates that the rule matches even -when eavesdropping. eavesdrop="false" is the default and means that -the rule only allows messages to go to their specified recipient. -For <deny>, eavesdrop="true" indicates that the rule matches -only when eavesdropping. eavesdrop="false" is the default for <deny> -also, but here it means that the rule applies always, even when -not eavesdropping. The eavesdrop attribute can only be combined with -receive rules (with receive_* attributes). - - - -The [send|receive]_requested_reply attribute works similarly to the eavesdrop -attribute. It controls whether the <deny> or <allow> matches a reply -that is expected (corresponds to a previous method call message). -This attribute only makes sense for reply messages (errors and method -returns), and is ignored for other message types. - - -For <allow>, [send|receive]_requested_reply="true" is the default and indicates that -only requested replies are allowed by the -rule. [send|receive]_requested_reply="false" means that the rule allows any reply -even if unexpected. - - -For <deny>, [send|receive]_requested_reply="false" is the default but indicates that -the rule matches only when the reply was not -requested. [send|receive]_requested_reply="true" indicates that the rule applies -always, regardless of pending reply state. - - -user and group denials mean that the given user or group may -not connect to the message bus. - - -For "name", "username", "groupname", etc. -the character "*" can be substituted, meaning "any." Complex globs -like "foo.bar.*" aren't allowed for now because they'd be work to -implement and maybe encourage sloppy security anyway. - -<allow own_prefix="a.b"/> allows you to own the name "a.b" or any -name whose first dot-separated elements are "a.b": in particular, -you can own "a.b.c" or "a.b.c.d", but not "a.bc" or "a.c". -This is useful when services like Telepathy and ReserveDevice -define a meaning for subtrees of well-known names, such as -org.freedesktop.Telepathy.ConnectionManager.(anything) -and org.freedesktop.ReserveDevice1.(anything). - -It does not make sense to deny a user or group inside a <policy> -for a user or group; user/group denials can only be inside -context="default" or context="mandatory" policies. - - -A single <deny> rule may specify combinations of attributes such as -send_destination and send_interface and send_type. In this case, the -denial applies only if both attributes match the message being denied. -e.g. <deny send_interface="foo.bar" send_destination="foo.blah"/> would -deny messages with the given interface AND the given bus name. -To get an OR effect you specify multiple <deny> rules. - - -You can't include both send_ and receive_ attributes on the same -rule, since "whether the message can be sent" and "whether it can be -received" are evaluated separately. - - -Be careful with send_interface/receive_interface, because the -interface field in messages is optional. - - - - <selinux> - - - - - - - -The <selinux> element contains settings related to Security Enhanced Linux. -More details below. - - - - <associate> - - - - - - - -An <associate> element appears below an <selinux> element and -creates a mapping. Right now only one kind of association is possible: - - <associate own="org.freedesktop.Foobar" context="foo_t"/> - - - -This means that if a connection asks to own the name -"org.freedesktop.Foobar" then the source context will be the context -of the connection and the target context will be "foo_t" - see the -short discussion of SELinux below. - - -Note, the context here is the target context when requesting a name, -NOT the context of the connection owning the name. - - -There's currently no way to set a default for owning any name, if -we add this syntax it will look like: - - <associate own="*" context="foo_t"/> - -If you find a reason this is useful, let the developers know. -Right now the default will be the security context of the bus itself. - - -If two <associate> elements specify the same name, the element -appearing later in the configuration file will be used. - - - -SELinux -See http://www.nsa.gov/selinux/ for full details on SELinux. Some useful excerpts: - - -Every subject (process) and object (e.g. file, socket, IPC object, -etc) in the system is assigned a collection of security attributes, -known as a security context. A security context contains all of the -security attributes associated with a particular subject or object -that are relevant to the security policy. - - -In order to better encapsulate security contexts and to provide -greater efficiency, the policy enforcement code of SELinux typically -handles security identifiers (SIDs) rather than security contexts. A -SID is an integer that is mapped by the security server to a security -context at runtime. - - -When a security decision is required, the policy enforcement code -passes a pair of SIDs (typically the SID of a subject and the SID of -an object, but sometimes a pair of subject SIDs or a pair of object -SIDs), and an object security class to the security server. The object -security class indicates the kind of object, e.g. a process, a regular -file, a directory, a TCP socket, etc. - - -Access decisions specify whether or not a permission is granted for a -given pair of SIDs and class. Each object class has a set of -associated permissions defined to control operations on objects with -that class. - - -D-Bus performs SELinux security checks in two places. - - -First, any time a message is routed from one connection to another -connection, the bus daemon will check permissions with the security context of -the first connection as source, security context of the second connection -as target, object class "dbus" and requested permission "send_msg". - - -If a security context is not available for a connection -(impossible when using UNIX domain sockets), then the target -context used is the context of the bus daemon itself. -There is currently no way to change this default, because we're -assuming that only UNIX domain sockets will be used to -connect to the systemwide bus. If this changes, we'll -probably add a way to set the default connection context. - - -Second, any time a connection asks to own a name, -the bus daemon will check permissions with the security -context of the connection as source, the security context specified -for the name in the config file as target, object -class "dbus" and requested permission "acquire_svc". - - -The security context for a bus name is specified with the -<associate> element described earlier in this document. -If a name has no security context associated in the -configuration file, the security context of the bus daemon -itself will be used. - - - -AUTHOR -See http://www.freedesktop.org/software/dbus/doc/AUTHORS - - - -BUGS -Please send bug reports to the D-Bus mailing list or bug tracker, -see http://www.freedesktop.org/software/dbus/ - - - diff --git a/cmake/doc/CMakeLists.txt b/cmake/doc/CMakeLists.txt index e107918..8bceded 100644 --- a/cmake/doc/CMakeLists.txt +++ b/cmake/doc/CMakeLists.txt @@ -96,10 +96,11 @@ DOCBOOK(${CMAKE_SOURCE_DIR}/../doc/dbus-test-plan.xml html-nochunks) DOCBOOK(${CMAKE_SOURCE_DIR}/../doc/dbus-tutorial.xml html-nochunks) DOCBOOK(${CMAKE_SOURCE_DIR}/../doc/dbus-specification.xml html-nochunks) DOCBOOK(${CMAKE_SOURCE_DIR}/../doc/dbus-faq.xml html-nochunks) -DOCBOOK(${CMAKE_SOURCE_DIR}/bus/dbus-daemon.xml html-nochunks) -DOCBOOK(${CMAKE_SOURCE_DIR}/tools/dbus-monitor.xml html-nochunks) -DOCBOOK(${CMAKE_SOURCE_DIR}/tools/dbus-send.xml html-nochunks) -DOCBOOK(${CMAKE_SOURCE_DIR}/tools/dbus-launch.xml html-nochunks) +configure_file(${CMAKE_SOURCE_DIR}/../doc/dbus-daemon.1.xml.in ${CMAKE_BINARY_DIR}/doc/dbus-daemon.1.xml) +DOCBOOK(${CMAKE_BINARY_DIR}/doc/dbus-daemon.1.xml html-nochunks) +DOCBOOK(${CMAKE_SOURCE_DIR}/../doc/dbus-monitor.1.xml html-nochunks) +DOCBOOK(${CMAKE_SOURCE_DIR}/../doc/dbus-send.1.xml html-nochunks) +DOCBOOK(${CMAKE_SOURCE_DIR}/../doc/dbus-launch.1.xml html-nochunks) # # handle html index file diff --git a/cmake/tools/dbus-launch.xml b/cmake/tools/dbus-launch.xml deleted file mode 100644 index dc34898..0000000 --- a/cmake/tools/dbus-launch.xml +++ /dev/null @@ -1,240 +0,0 @@ - - - - - - - - - -dbus-launch -1 - - -dbus-launch -Utility to start a message bus from a shell script - - - - - dbus-launch --version - --sh-syntax - --csh-syntax - --auto-syntax - --exit-with-session - --autolaunch=MACHINEID - --config-file=FILENAME - PROGRAM - ARGS - - - - - -DESCRIPTION -The dbus-launch command is used to start a session bus -instance of dbus-daemon from a shell script. -It would normally be called from a user's login -scripts. Unlike the daemon itself, dbus-launch exits, so -backticks or the $() construct can be used to read information from -dbus-launch. - -With no arguments, dbus-launch will launch a session bus -instance and print the address and pid of that instance to standard -output. - -You may specify a program to be run; in this case, dbus-launch -will launch a session bus instance, set the appropriate environment -variables so the specified program can find the bus, and then execute the -specified program, with the specified arguments. See below for -examples. - -If you launch a program, dbus-launch will not print the -information about the new bus to standard output. - -When dbus-launch prints bus information to standard output, by -default it is in a simple key-value pairs format. However, you may -request several alternate syntaxes using the --sh-syntax, --csh-syntax, ---binary-syntax, or ---auto-syntax options. Several of these cause dbus-launch to emit shell code -to set up the environment. - -With the --auto-syntax option, dbus-launch looks at the value -of the SHELL environment variable to determine which shell syntax -should be used. If SHELL ends in "csh", then csh-compatible code is -emitted; otherwise Bourne shell code is emitted. Instead of passing ---auto-syntax, you may explicity specify a particular one by using ---sh-syntax for Bourne syntax, or --csh-syntax for csh syntax. -In scripts, it's more robust to avoid --auto-syntax and you hopefully -know which shell your script is written in. - - -See http://www.freedesktop.org/software/dbus/ for more information -about D-Bus. See also the man page for dbus-daemon. - - -Here is an example of how to use dbus-launch with an -sh-compatible shell to start the per-session bus daemon: - - - ## test for an existing bus daemon, just to be safe - if test -z "$DBUS_SESSION_BUS_ADDRESS" ; then - ## if not found, launch a new one - eval `dbus-launch --sh-syntax --exit-with-session` - echo "D-Bus per-session daemon address is: $DBUS_SESSION_BUS_ADDRESS" - fi - - -You might run something like that in your login scripts. - - -Another way to use dbus-launch is to run your main session -program, like so: - - -dbus-launch gnome-session - - -The above would likely be appropriate for ~/.xsession or ~/.Xclients. - - - -AUTOMATIC LAUNCHING -If DBUS_SESSION_BUS_ADDRESS is not set for a process that tries to use -D-Bus, by default the process will attempt to invoke dbus-launch with -the --autolaunch option to start up a new session bus or find the -existing bus address on the X display or in a file in -~/.dbus/session-bus/ - - -Whenever an autolaunch occurs, the application that had to -start a new bus will be in its own little world; it can effectively -end up starting a whole new session if it tries to use a lot of -bus services. This can be suboptimal or even totally broken, depending -on the app and what it tries to do. - - -There are two common reasons for autolaunch. One is ssh to a remote -machine. The ideal fix for that would be forwarding of -DBUS_SESSION_BUS_ADDRESS in the same way that DISPLAY is forwarded. -In the meantime, you can edit the session.conf config file to -have your session bus listen on TCP, and manually set -DBUS_SESSION_BUS_ADDRESS, if you like. - - -The second common reason for autolaunch is an su to another user, and -display of X applications running as the second user on the display -belonging to the first user. Perhaps the ideal fix in this case -would be to allow the second user to connect to the session bus of the -first user, just as they can connect to the first user's display. -However, a mechanism for that has not been coded. - - -You can always avoid autolaunch by manually setting -DBUS_SESSION_BUS_ADDRESS. Autolaunch happens because the default -address if none is set is "autolaunch:", so if any other address is -set there will be no autolaunch. You can however include autolaunch in -an explicit session bus address as a fallback, for example -DBUS_SESSION_BUS_ADDRESS="something:,autolaunch:" - in that case if -the first address doesn't work, processes will autolaunch. (The bus -address variable contains a comma-separated list of addresses to try.) - - -The --autolaunch option is considered an internal implementation -detail of libdbus, and in fact there are plans to change it. There's -no real reason to use it outside of the libdbus implementation anyhow. - - - -OPTIONS -The following options are supported: - - - - -Choose --csh-syntax or --sh-syntax based on the SHELL environment variable. - - -Write to stdout a nul-terminated bus address, then the bus PID as a -binary integer of size sizeof(pid_t), then the bus X window ID as a -binary integer of size sizeof(long). Integers are in the machine's -byte order, not network byte order or any other canonical byte order. - - - - - - -Close the standard error output stream before starting the D-Bus -daemon. This is useful if you want to capture dbus-launch error -messages but you don't want dbus-daemon to keep the stream open to -your application. - - - - - - -Pass --config-file=FILENAME to the bus daemon, instead of passing it -the --session argument. See the man page for dbus-daemon - - - - - - -Emit csh compatible code to set up environment variables. - - - - - - -If this option is provided, a persistent "babysitter" process will be -created that watches stdin for HUP and tries to connect to the X -server. If this process gets a HUP on stdin or loses its X connection, -it kills the message bus daemon. - - - - - - -This option implies that dbus-launch should scan for a -previously-started session and reuse the values found there. If no -session is found, it will start a new session. The ---exit-with-session option is implied if --autolaunch is given. -This option is for the exclusive use of libdbus, you do not want to -use it manually. It may change in the future. - - - - - - -Emit Bourne-shell compatible code to set up environment variables. - - - - - - -Print the version of dbus-launch - - - - - - -AUTHOR -See http://www.freedesktop.org/software/dbus/doc/AUTHORS - - - -BUGS -Please send bug reports to the D-Bus mailing list or bug tracker, -see http://www.freedesktop.org/software/dbus/ - - - diff --git a/cmake/tools/dbus-monitor.xml b/cmake/tools/dbus-monitor.xml deleted file mode 100644 index b41cace..0000000 --- a/cmake/tools/dbus-monitor.xml +++ /dev/null @@ -1,121 +0,0 @@ - - - - - - - - - -dbus-monitor -1 - - -dbus-monitor -debug probe to print message bus messages - - - - - dbus-monitor - --system --session --address ADDRESS - --profile --monitor - watchexpressions - - - - - -DESCRIPTION -The dbus-monitor command is used to monitor messages going -through a D-Bus message bus. See -http://www.freedesktop.org/software/dbus/ for more information about -the big picture. - - -There are two well-known message buses: the systemwide message bus -(installed on many systems as the "messagebus" service) and the -per-user-login-session message bus (started each time a user logs in). -The --system and --session options direct dbus-monitor to -monitor the system or session buses respectively. If neither is -specified, dbus-monitor monitors the session bus. - - -dbus-monitor has two different output modes, the 'classic'-style -monitoring mode and profiling mode. The profiling format is a compact -format with a single line per message and microsecond-resolution timing -information. The --profile and --monitor options select the profiling -and monitoring output format respectively. If neither is specified, -dbus-monitor uses the monitoring output format. - - -In order to get dbus-monitor to see the messages you are interested -in, you should specify a set of watch expressions as you would expect to -be passed to the dbus_bus_add_match function. - - -The message bus configuration may keep dbus-monitor from seeing -all messages, especially if you run the monitor as a non-root user. - - - -OPTIONS - - - - -Monitor the system message bus. - - - - - -Monitor the session message bus. (This is the default.) - - - - - -Monitor an arbitrary message bus given at ADDRESS. - - - - - -Use the profiling output format. - - - - - -Use the monitoring output format. (This is the default.) - - - - - - -EXAMPLE -Here is an example of using dbus-monitor to watch for the gnome typing -monitor to say things - - - dbus-monitor "type='signal',sender='org.gnome.TypingMonitor',interface='org.gnome.TypingMonitor'" - - - - - -AUTHOR -dbus-monitor was written by Philip Blundell. -The profiling output mode was added by Olli Salli. - - - -BUGS -Please send bug reports to the D-Bus mailing list or bug tracker, -see http://www.freedesktop.org/software/dbus/ - - - diff --git a/cmake/tools/dbus-send.xml b/cmake/tools/dbus-send.xml deleted file mode 100644 index 7fefc03..0000000 --- a/cmake/tools/dbus-send.xml +++ /dev/null @@ -1,143 +0,0 @@ - - - - - - - - - -dbus-send -1 - - -dbus-send -Send a message to a message bus - - - - - dbus-send - --system --session - --dest=NAME - --print-reply - --type=TYPE - <destination - object - path> - <message - name> - contents - - - - - -DESCRIPTION -The dbus-send command is used to send a message to a D-Bus message -bus. See http://www.freedesktop.org/software/dbus/ for more -information about the big picture. - - -There are two well-known message buses: the systemwide message bus -(installed on many systems as the "messagebus" service) and the -per-user-login-session message bus (started each time a user logs in). -The --system and --session options direct dbus-send to send -messages to the system or session buses respectively. If neither is -specified, dbus-send sends to the session bus. - - -Nearly all uses of dbus-send must provide the --dest argument -which is the name of a connection on the bus to send the message to. If ---dest is omitted, no destination is set. - - -The object path and the name of the message to send must always be -specified. Following arguments, if any, are the message contents -(message arguments). These are given as type-specified values and -may include containers (arrays, dicts, and variants) as described below. - - -<contents> ::= <item> | <container> [ <item> | <container>...] -<item> ::= <type>:<value> -<container> ::= <array> | <dict> | <variant> -<array> ::= array:<type>:<value>[,<value>...] -<dict> ::= dict:<type>:<type>:<key>,<value>[,<key>,<value>...] -<variant> ::= variant:<type>:<value> -<type> ::= string | int16 | uint 16 | int32 | uint32 | int64 | uint64 | double | byte | boolean | objpath - - -D-Bus supports more types than these, but dbus-send currently -does not. Also, dbus-send does not permit empty containers -or nested containers (e.g. arrays of variants). - - -Here is an example invocation: - - - dbus-send --dest=org.freedesktop.ExampleName \ - /org/freedesktop/sample/object/name \ - org.freedesktop.ExampleInterface.ExampleMethod \ - int32:47 string:'hello world' double:65.32 \ - array:string:"1st item","next item","last item" \ - dict:string:int32:"one",1,"two",2,"three",3 \ - variant:int32:-8 \ - objpath:/org/freedesktop/sample/object/name - - - -Note that the interface is separated from a method or signal -name by a dot, though in the actual protocol the interface -and the interface member are separate fields. - - - -OPTIONS -The following options are supported: - - - - -Specify the name of the connection to receive the message. - - - - - -Block for a reply to the message sent, and print any reply received. - - - - - -Send to the system message bus. - - - - - -Send to the session message bus. (This is the default.) - - - - - -Specify "method_call" or "signal" (defaults to "signal"). - - - - - - -AUTHOR -dbus-send was written by Philip Blundell. - - - -BUGS -Please send bug reports to the D-Bus mailing list or bug tracker, -see http://www.freedesktop.org/software/dbus/ - - - diff --git a/doc/dbus-daemon.1.xml.in b/doc/dbus-daemon.1.xml.in new file mode 100644 index 0000000..bc602bb --- /dev/null +++ b/doc/dbus-daemon.1.xml.in @@ -0,0 +1,888 @@ + + + + + + + + +dbus-daemon +1 + + +dbus-daemon +Message bus daemon + + + + + dbus-daemon + + dbus-daemon --version + --session + --system + --config-file=FILE + --print-address =DESCRIPTOR + --print-pid =DESCRIPTOR + --fork + + + + + +DESCRIPTION +dbus-daemon is the D-Bus message bus daemon. See +http://www.freedesktop.org/software/dbus/ for more information about +the big picture. D-Bus is first a library that provides one-to-one +communication between any two applications; dbus-daemon is an +application that uses this library to implement a message bus +daemon. Multiple programs connect to the message bus daemon and can +exchange messages with one another. + +There are two standard message bus instances: the systemwide message bus +(installed on many systems as the "messagebus" init service) and the +per-user-login-session message bus (started each time a user logs in). +dbus-daemon is used for both of these instances, but with +a different configuration file. + +The --session option is equivalent to +"--config-file=@EXPANDED_SYSCONFDIR@/dbus-1/session.conf" and the --system +option is equivalent to +"--config-file=@EXPANDED_SYSCONFDIR@/dbus-1/system.conf". By creating +additional configuration files and using the --config-file option, +additional special-purpose message bus daemons could be created. + +The systemwide daemon is normally launched by an init script, +standardly called simply "messagebus". + +The systemwide daemon is largely used for broadcasting system events, +such as changes to the printer queue, or adding/removing devices. + +The per-session daemon is used for various interprocess communication +among desktop applications (however, it is not tied to X or the GUI +in any way). + +SIGHUP will cause the D-Bus daemon to PARTIALLY reload its +configuration file and to flush its user/group information caches. Some +configuration changes would require kicking all apps off the bus; so they will +only take effect if you restart the daemon. Policy changes should take effect +with SIGHUP. + + + +OPTIONS +The following options are supported: + + + + +Use the given configuration file. + + + + + +Force the message bus to fork and become a daemon, even if +the configuration file does not specify that it should. +In most contexts the configuration file already gets this +right, though. + +Force the message bus not to fork and become a daemon, even if +the configuration file specifies that it should. + + + + + +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. This is used by programs that +launch the message bus. + + + + + +Use the standard configuration file for the per-login-session message +bus. + + + + + +Use the standard configuration file for the systemwide message bus. + + + + + +Print the version of the daemon. + + + + + +Print the introspection information for all D-Bus internal interfaces. + + + + + +Set the address to listen on. This option overrides the address +configured in the configuration file. + + + + + +Enable systemd-style service activation. Only useful in conjunction +with the systemd system and session manager on Linux. + + + + + +Don't write a PID file even if one is configured in the configuration +files. + + + + + + +CONFIGURATION FILE +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 also establishes resource limits, security +parameters, and so forth. + +The configuration file is not part of any interoperability +specification and its backward compatibility is not guaranteed; this +document is documentation, not specification. + +The standard systemwide and per-session message bus setups are +configured in the files "@EXPANDED_SYSCONFDIR@/dbus-1/system.conf" and +"@EXPANDED_SYSCONFDIR@/dbus-1/session.conf". These files normally +<include> a system-local.conf or session-local.conf; you can put local +overrides in those files to avoid modifying the primary configuration +files. + + +The configuration file is an XML document. It must have the following +doctype declaration: + + + <!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-Bus Bus Configuration 1.0//EN" + "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd"> + + + + +The following elements may be present in the configuration file. + + + + <busconfig> + + + + +Root element. + + + + <type> + + + + +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. The last +<type> element "wins" (previous values are ignored). 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 well-known type of the message bus is "session", then the +DBUS_STARTER_BUS_TYPE environment variable will be set to "session" +and the DBUS_SESSION_BUS_ADDRESS environment variable will be set +to the address of the session bus. Likewise, if the type of the +message bus is "system", then the DBUS_STARTER_BUS_TYPE environment +variable will be set to "system" and the DBUS_SESSION_BUS_ADDRESS +environment variable will be set to the address of the system bus +(which is normally well known anyway). + + +Example: <type>session</type> + + + + <include> + + + + +Include a file <include>filename.conf</include> at this point. If the +filename is relative, it is located relative to the configuration file +doing the including. + + +<include> has an optional attribute "ignore_missing=(yes|no)" +which defaults to "no" if not provided. This attribute +controls whether it's a fatal error for the included file +to be absent. + + + + <includedir> + + + + +Include all files in <includedir>foo.d</includedir> at this +point. Files in the directory are included in undefined order. +Only files ending in ".conf" are included. + + +This is intended to allow extension of the system bus by particular +packages. For example, if CUPS wants to be able to send out +notification of printer queue changes, it could install a file to +@EXPANDED_SYSCONFDIR@/dbus-1/system.d that allowed all apps to receive +this message and allowed the printer daemon user to send it. + + + + <user> + + + + +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 last <user> entry in the file "wins", the others are ignored. + + +The user is changed after the bus has completed initialization. So +sockets etc. will be created before changing user, but no data will be +read from clients before changing user. This means that sockets +and PID files can be created in a location that requires root +privileges for writing. + + + + <fork> + + + + +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. + + + + <keep_umask> + + + + +If present, the bus daemon keeps its original umask when forking. +This may be useful to avoid affecting the behavior of child processes. + + + + <listen> + + + + +Add an address that the bus should listen on. The +address is in the standard D-Bus format that contains +a transport name plus possible parameters/options. + + +Example: <listen>unix:path=/tmp/foo</listen> + + +Example: <listen>tcp:host=localhost,port=1234</listen> + + +If there are multiple <listen> elements, then the bus listens +on multiple addresses. The bus will pass its address to +started services or other interested parties with +the last address given in <listen> first. That is, +apps will try to connect to the last <listen> address first. + + +tcp sockets can accept IPv4 addresses, IPv6 addresses or hostnames. +If a hostname resolves to multiple addresses, the server will bind +to all of them. The family=ipv4 or family=ipv6 options can be used +to force it to bind to a subset of addresses + + +Example: <listen>tcp:host=localhost,port=0,family=ipv4</listen> + + +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. The port number chosen can be obtained with the +--print-address command line parameter and will be present in other +cases where the server reports its own address, such as when +DBUS_SESSION_BUS_ADDRESS is set. + + +Example: <listen>tcp:host=localhost,port=0</listen> + + +tcp addresses also allow a bind=hostname option, which will override +the host option specifying what address to bind to, without changing +the address reported by the bus. The bind option can also take a +special name '*' to cause the bus to listen on all local address +(INADDR_ANY). The specified host should be a valid name of the local +machine or weird stuff will happen. + + +Example: <listen>tcp:host=localhost,bind=*,port=0</listen> + + + + <auth> + + + + +Lists permitted authorization mechanisms. If this element doesn't +exist, then all known mechanisms are allowed. If there are multiple +<auth> elements, all the listed mechanisms are allowed. The order in +which mechanisms are listed is not meaningful. + + +Example: <auth>EXTERNAL</auth> + + +Example: <auth>DBUS_COOKIE_SHA1</auth> + + + + <servicedir> + + + + +Adds a directory to scan for .service files. Directories are +scanned starting with the last to appear in the config file +(the first .service file found that provides a particular +service will be used). + + +Service files tell the bus how to automatically start a program. +They are primarily used with the per-user-session bus, +not the systemwide bus. + + + + <standard_session_servicedirs/> + + + + +<standard_session_servicedirs/> is equivalent to specifying a series +of <servicedir/> elements for each of the data directories in the "XDG +Base Directory Specification" with the subdirectory "dbus-1/services", +so for example "/usr/share/dbus-1/services" would be among the +directories searched. + + +The "XDG Base Directory Specification" can be found at +http://freedesktop.org/wiki/Standards/basedir-spec if it hasn't moved, +otherwise try your favorite search engine. + + +The <standard_session_servicedirs/> option is only relevant to the +per-user-session bus daemon defined in +@EXPANDED_SYSCONFDIR@/dbus-1/session.conf. Putting it in any other +configuration file would probably be nonsense. + + + + <standard_system_servicedirs/> + + + + +<standard_system_servicedirs/> specifies the standard system-wide +activation directories that should be searched for service files. +This option defaults to @EXPANDED_DATADIR@/dbus-1/system-services. + + +The <standard_system_servicedirs/> option is only relevant to the +per-system bus daemon defined in +@EXPANDED_SYSCONFDIR@/dbus-1/system.conf. Putting it in any other +configuration file would probably be nonsense. + + + + <servicehelper/> + + + + +<servicehelper/> specifies the setuid helper that is used to launch +system daemons with an alternate user. Typically this should be +the dbus-daemon-launch-helper executable in located in libexec. + + +The <servicehelper/> option is only relevant to the per-system bus daemon +defined in @EXPANDED_SYSCONFDIR@/dbus-1/system.conf. Putting it in any other +configuration file would probably be nonsense. + + + + <limit> + + + + +<limit> establishes a resource limit. For example: + + <limit name="max_message_size">64</limit> + <limit name="max_completed_connections">512</limit> + + + +The name attribute is mandatory. +Available limit names are: + + "max_incoming_bytes" : total size in bytes of messages + incoming from a single connection + "max_incoming_unix_fds" : total number of unix fds of messages + incoming from a single connection + "max_outgoing_bytes" : total size in bytes of messages + queued up for a single connection + "max_outgoing_unix_fds" : total number of unix fds of messages + queued up for a single connection + "max_message_size" : max size of a single message in + bytes + "max_message_unix_fds" : max unix fds of a single message + "service_start_timeout" : milliseconds (thousandths) until + a started service has to connect + "auth_timeout" : milliseconds (thousandths) a + connection is given to + authenticate + "max_completed_connections" : max number of authenticated connections + "max_incomplete_connections" : max number of unauthenticated + connections + "max_connections_per_user" : max number of completed connections from + the same user + "max_pending_service_starts" : max number of service launches in + progress at the same time + "max_names_per_connection" : max number of names a single + connection can own + "max_match_rules_per_connection": max number of match rules for a single + connection + "max_replies_per_connection" : max number of pending method + replies per connection + (number of calls-in-progress) + "reply_timeout" : milliseconds (thousandths) + until a method call times out + + + +The max incoming/outgoing queue sizes allow a new message to be queued +if one byte remains below the max. So you can in fact exceed the max +by max_message_size. + + +max_completed_connections divided by max_connections_per_user is the +number of users that can work together to denial-of-service all other users by using +up all connections on the systemwide bus. + + +Limits are normally only of interest on the systemwide bus, not the user session +buses. + + + + <policy> + + + + +The <policy> element defines a security policy to be applied to a particular +set of connections to the bus. A policy is made up of +<allow> and <deny> elements. Policies are normally used with the systemwide bus; +they are analogous to a firewall in that they allow expected traffic +and prevent unexpected traffic. + + +Currently, the system bus has a default-deny policy for sending method calls +and owning bus names. Everything else, in particular reply messages, receive +checks, and signals has a default allow policy. + + +In general, it is best to keep system services as small, targeted programs which +run in their own process and provide a single bus name. Then, all that is needed +is an <allow> rule for the "own" permission to let the process claim the bus +name, and a "send_destination" rule to allow traffic from some or all uids to +your service. + + +The <policy> element has one of four attributes: + + context="(default|mandatory)" + at_console="(true|false)" + user="username or userid" + group="group name or gid" + + + +Policies are applied to a connection as follows: + + - all context="default" policies are applied + - all group="connection's user's group" policies are applied + in undefined order + - all user="connection's auth user" policies are applied + in undefined order + - all at_console="true" policies are applied + - all at_console="false" policies are applied + - all context="mandatory" policies are applied + + + +Policies applied later will override those applied earlier, +when the policies overlap. Multiple policies with the same +user/group/context are applied in the order they appear +in the config file. + + + + <deny> + +<allow> + + + + + +A <deny> element appears below a <policy> element and prohibits some +action. The <allow> element makes an exception to previous <deny> +statements, and works just like <deny> but with the inverse meaning. + + +The possible attributes of these elements are: + + send_interface="interface_name" + send_member="method_or_signal_name" + send_error="error_name" + send_destination="name" + send_type="method_call" | "method_return" | "signal" | "error" + send_path="/path/name" + + receive_interface="interface_name" + receive_member="method_or_signal_name" + receive_error="error_name" + receive_sender="name" + receive_type="method_call" | "method_return" | "signal" | "error" + receive_path="/path/name" + + send_requested_reply="true" | "false" + receive_requested_reply="true" | "false" + + eavesdrop="true" | "false" + + own="name" + own_prefix="name" + user="username" + group="groupname" + + + +Examples: + + <deny send_destination="org.freedesktop.Service" send_interface="org.freedesktop.System" send_member="Reboot"/> + <deny send_destination="org.freedesktop.System"/> + <deny receive_sender="org.freedesktop.System"/> + <deny user="john"/> + <deny group="enemies"/> + + + +The <deny> element's attributes determine whether the deny "matches" a +particular action. If it matches, the action is denied (unless later +rules in the config file allow it). + +send_destination and receive_sender rules mean that messages may not be +sent to or received from the *owner* of the given name, not that +they may not be sent *to that name*. That is, if a connection +owns services A, B, C, and sending to A is denied, sending to B or C +will not work either. + +The other send_* and receive_* attributes are purely textual/by-value +matches against the given field in the message header. + +"Eavesdropping" occurs when an application receives a message that +was explicitly addressed to a name the application does not own, or +is a reply to such a message. Eavesdropping thus only applies to +messages that are addressed to services and replies to such messages +(i.e. it does not apply to signals). + +For <allow>, eavesdrop="true" indicates that the rule matches even +when eavesdropping. eavesdrop="false" is the default and means that +the rule only allows messages to go to their specified recipient. +For <deny>, eavesdrop="true" indicates that the rule matches +only when eavesdropping. eavesdrop="false" is the default for <deny> +also, but here it means that the rule applies always, even when +not eavesdropping. The eavesdrop attribute can only be combined with +send and receive rules (with send_* and receive_* attributes). + +The [send|receive]_requested_reply attribute works similarly to the eavesdrop +attribute. It controls whether the <deny> or <allow> matches a reply +that is expected (corresponds to a previous method call message). +This attribute only makes sense for reply messages (errors and method +returns), and is ignored for other message types. + + +For <allow>, [send|receive]_requested_reply="true" is the default and indicates that +only requested replies are allowed by the +rule. [send|receive]_requested_reply="false" means that the rule allows any reply +even if unexpected. + + +For <deny>, [send|receive]_requested_reply="false" is the default but indicates that +the rule matches only when the reply was not +requested. [send|receive]_requested_reply="true" indicates that the rule applies +always, regardless of pending reply state. + + +user and group denials mean that the given user or group may +not connect to the message bus. + + +For "name", "username", "groupname", etc. +the character "*" can be substituted, meaning "any." Complex globs +like "foo.bar.*" aren't allowed for now because they'd be work to +implement and maybe encourage sloppy security anyway. + + +<allow own_prefix="a.b"/> allows you to own the name "a.b" or any +name whose first dot-separated elements are "a.b": in particular, +you can own "a.b.c" or "a.b.c.d", but not "a.bc" or "a.c". +This is useful when services like Telepathy and ReserveDevice +define a meaning for subtrees of well-known names, such as +org.freedesktop.Telepathy.ConnectionManager.(anything) +and org.freedesktop.ReserveDevice1.(anything). + + +It does not make sense to deny a user or group inside a <policy> +for a user or group; user/group denials can only be inside +context="default" or context="mandatory" policies. + + +A single <deny> rule may specify combinations of attributes such as +send_destination and send_interface and send_type. In this case, the +denial applies only if both attributes match the message being denied. +e.g. <deny send_interface="foo.bar" send_destination="foo.blah"/> would +deny messages with the given interface AND the given bus name. +To get an OR effect you specify multiple <deny> rules. + + +You can't include both send_ and receive_ attributes on the same +rule, since "whether the message can be sent" and "whether it can be +received" are evaluated separately. + + +Be careful with send_interface/receive_interface, because the +interface field in messages is optional. In particular, do NOT +specify <deny send_interface="org.foo.Bar"/>! This will cause +no-interface messages to be blocked for all services, which is +almost certainly not what you intended. Always use rules of +the form: <deny send_interface="org.foo.Bar" send_destination="org.foo.Service"/> + + + + <selinux> + + + + +The <selinux> element contains settings related to Security Enhanced Linux. +More details below. + + + + <associate> + + + + +An <associate> element appears below an <selinux> element and +creates a mapping. Right now only one kind of association is possible: + + <associate own="org.freedesktop.Foobar" context="foo_t"/> + + + +This means that if a connection asks to own the name +"org.freedesktop.Foobar" then the source context will be the context +of the connection and the target context will be "foo_t" - see the +short discussion of SELinux below. + + +Note, the context here is the target context when requesting a name, +NOT the context of the connection owning the name. + + +There's currently no way to set a default for owning any name, if +we add this syntax it will look like: + + <associate own="*" context="foo_t"/> + +If you find a reason this is useful, let the developers know. +Right now the default will be the security context of the bus itself. + + +If two <associate> elements specify the same name, the element +appearing later in the configuration file will be used. + + + +SELinux +See http://www.nsa.gov/selinux/ for full details on SELinux. Some useful excerpts: + + +Every subject (process) and object (e.g. file, socket, IPC object, +etc) in the system is assigned a collection of security attributes, +known as a security context. A security context contains all of the +security attributes associated with a particular subject or object +that are relevant to the security policy. + + +In order to better encapsulate security contexts and to provide +greater efficiency, the policy enforcement code of SELinux typically +handles security identifiers (SIDs) rather than security contexts. A +SID is an integer that is mapped by the security server to a security +context at runtime. + + +When a security decision is required, the policy enforcement code +passes a pair of SIDs (typically the SID of a subject and the SID of +an object, but sometimes a pair of subject SIDs or a pair of object +SIDs), and an object security class to the security server. The object +security class indicates the kind of object, e.g. a process, a regular +file, a directory, a TCP socket, etc. + + +Access decisions specify whether or not a permission is granted for a +given pair of SIDs and class. Each object class has a set of +associated permissions defined to control operations on objects with +that class. + + +D-Bus performs SELinux security checks in two places. + + +First, any time a message is routed from one connection to another +connection, the bus daemon will check permissions with the security context of +the first connection as source, security context of the second connection +as target, object class "dbus" and requested permission "send_msg". + + +If a security context is not available for a connection +(impossible when using UNIX domain sockets), then the target +context used is the context of the bus daemon itself. +There is currently no way to change this default, because we're +assuming that only UNIX domain sockets will be used to +connect to the systemwide bus. If this changes, we'll +probably add a way to set the default connection context. + + +Second, any time a connection asks to own a name, +the bus daemon will check permissions with the security +context of the connection as source, the security context specified +for the name in the config file as target, object +class "dbus" and requested permission "acquire_svc". + + +The security context for a bus name is specified with the +<associate> element described earlier in this document. +If a name has no security context associated in the +configuration file, the security context of the bus daemon +itself will be used. + + + +DEBUGGING +If you're trying to figure out where your messages are going or why +you aren't getting messages, there are several things you can try. + +Remember that the system bus is heavily locked down and if you +haven't installed a security policy file to allow your message +through, it won't work. For the session bus, this is not a concern. + +The simplest way to figure out what's happening on the bus is to run +the dbus-monitor program, which comes with the D-Bus +package. You can also send test messages with dbus-send. These +programs have their own man pages. + +If you want to know what the daemon itself is doing, you might consider +running a separate copy of the daemon to test against. This will allow you +to put the daemon under a debugger, or run it with verbose output, without +messing up your real session and system daemons. + +To run a separate test copy of the daemon, for example you might open a terminal +and type: + + DBUS_VERBOSE=1 dbus-daemon --session --print-address + + +The test daemon address will be printed when the daemon starts. You will need +to copy-and-paste this address and use it as the value of the +DBUS_SESSION_BUS_ADDRESS environment variable when you launch the applications +you want to test. This will cause those applications to connect to your +test bus instead of the DBUS_SESSION_BUS_ADDRESS of your real session bus. + +DBUS_VERBOSE=1 will have NO EFFECT unless your copy of D-Bus +was compiled with verbose mode enabled. This is not recommended in +production builds due to performance impact. You may need to rebuild +D-Bus if your copy was not built with debugging in mind. (DBUS_VERBOSE +also affects the D-Bus library and thus applications using D-Bus; it may +be useful to see verbose output on both the client side and from the daemon.) + +If you want to get fancy, you can create a custom bus +configuration for your test bus (see the session.conf and system.conf +files that define the two default configurations for example). This +would allow you to specify a different directory for .service files, +for example. + + + +AUTHOR +See http://www.freedesktop.org/software/dbus/doc/AUTHORS + + + +BUGS +Please send bug reports to the D-Bus mailing list or bug tracker, +see http://www.freedesktop.org/software/dbus/ + + + diff --git a/doc/dbus-daemon.xml.in b/doc/dbus-daemon.xml.in new file mode 100644 index 0000000..f331699 --- /dev/null +++ b/doc/dbus-daemon.xml.in @@ -0,0 +1,752 @@ + + + + + + + + + +dbus-daemon +1 + + +dbus-daemon +Message bus daemon + + + + + dbus-daemon + + dbus-daemon --version + --session + --system + --config-file=FILE + --print-address =DESCRIPTOR + --print-pid =DESCRIPTOR + --fork + + + + + +DESCRIPTION +dbus-daemon is the D-Bus message bus daemon. See +http://www.freedesktop.org/software/dbus/ for more information about +the big picture. D-Bus is first a library that provides one-to-one +communication between any two applications; dbus-daemon is an +application that uses this library to implement a message bus +daemon. Multiple programs connect to the message bus daemon and can +exchange messages with one another. + + +There are two standard message bus instances: the systemwide message bus +(installed on many systems as the "messagebus" init service) and the +per-user-login-session message bus (started each time a user logs in). +dbus-daemon is used for both of these instances, but with +a different configuration file. + + +The --session option is equivalent to +"--config-file=/etc/dbus-1/session.conf" and the --system +option is equivalent to +"--config-file=/etc/dbus-1/system.conf". By creating +additional configuration files and using the --config-file option, +additional special-purpose message bus daemons could be created. + + +The systemwide daemon is normally launched by an init script, +standardly called simply "messagebus". + + +The systemwide daemon is largely used for broadcasting system events, +such as changes to the printer queue, or adding/removing devices. + + +The per-session daemon is used for various interprocess communication +among desktop applications (however, it is not tied to X or the GUI +in any way). + + +SIGHUP will cause the D-Bus daemon to PARTIALLY reload its +configuration file and to flush its user/group information caches. Some +configuration changes would require kicking all apps off the bus; so they will +only take effect if you restart the daemon. Policy changes should take effect +with SIGHUP. + + + +OPTIONS +The following options are supported: + + + + +Use the given configuration file. + + + + + +Force the message bus to fork and become a daemon, even if +the configuration file does not specify that it should. +In most contexts the configuration file already gets this +right, though. + + + + + +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. This is used by programs that +launch the message bus. + + + + + +Use the standard configuration file for the per-login-session message +bus. + + + + + +Use the standard configuration file for the systemwide message bus. + + + + + +Print the version of the daemon. + + + + + + +CONFIGURATION FILE +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 also establishes resource limits, security +parameters, and so forth. + + +The configuration file is not part of any interoperability +specification and its backward compatibility is not guaranteed; this +document is documentation, not specification. + + +The standard systemwide and per-session message bus setups are +configured in the files "/etc/dbus-1/system.conf" and +"/etc/dbus-1/session.conf". These files normally +<include> a system-local.conf or session-local.conf; you can put local +overrides in those files to avoid modifying the primary configuration +files. + + +The configuration file is an XML document. It must have the following +doctype declaration: + + + <!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-Bus Bus Configuration 1.0//EN" + "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd"> + + + + +The following elements may be present in the configuration file. + + + + <busconfig> + + + + + + +Root element. + + + + <type> + + + + + + + +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. The last +<type> element "wins" (previous values are ignored). + + +Example: <type>session</type> + + + + <include> + + + + + + +Include a file <include>filename.conf</include> at this point. If the +filename is relative, it is located relative to the configuration file +doing the including. + + +<include> has an optional attribute "ignore_missing=(yes|no)" +which defaults to "no" if not provided. This attribute +controls whether it's a fatal error for the included file +to be absent. + + + + <includedir> + + + + + + + +Include all files in <includedir>foo.d</includedir> at this +point. Files in the directory are included in undefined order. +Only files ending in ".conf" are included. + + +This is intended to allow extension of the system bus by particular +packages. For example, if CUPS wants to be able to send out +notification of printer queue changes, it could install a file to +/etc/dbus-1/system.d that allowed all apps to receive +this message and allowed the printer daemon user to send it. + + + + <user> + + + + + + + +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 last <user> entry in the file "wins", the others are ignored. + + +The user is changed after the bus has completed initialization. So +sockets etc. will be created before changing user, but no data will be +read from clients before changing user. This means that sockets +and PID files can be created in a location that requires root +privileges for writing. + + + + <fork> + + + + + + +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. + + + + <listen> + + + + + + + +Add an address that the bus should listen on. The +address is in the standard D-Bus format that contains +a transport name plus possible parameters/options. + + +Example: <listen>unix:path=/tmp/foo</listen> + + +If there are multiple <listen> elements, then the bus listens +on multiple addresses. The bus will pass its address to +started services or other interested parties with +the last address given in <listen> first. That is, +apps will try to connect to the last <listen> address first. + + + + <auth> + + + + + + + +Lists permitted authorization mechanisms. If this element doesn't +exist, then all known mechanisms are allowed. If there are multiple +<auth> elements, all the listed mechanisms are allowed. The order in +which mechanisms are listed is not meaningful. + + +Example: <auth>EXTERNAL</auth> + + +Example: <auth>DBUS_COOKIE_SHA1</auth> + + + + <servicedir> + + + + + + + +Adds a directory to scan for .service files. Directories are +scanned starting with the last to appear in the config file +(the first .service file found that provides a particular +service will be used). + + +Service files tell the bus how to automatically start a program. +They are primarily used with the per-user-session bus, +not the systemwide bus. + + + + <standard_session_servicedirs/> + + + + + + + +<standard_session_servicedirs/> is equivalent to specifying a series +of <servicedir/> elements for each of the data directories in the "XDG +Base Directory Specification" with the subdirectory "dbus-1/services", +so for example "/usr/share/dbus-1/services" would be among the +directories searched. + + +The "XDG Base Directory Specification" can be found at +http://freedesktop.org/wiki/Standards/basedir-spec if it hasn't moved, +otherwise try your favorite search engine. + + +The <standard_session_servicedirs/> option is only relevant to the +per-user-session bus daemon defined in +/etc/dbus-1/session.conf. Putting it in any other +configuration file would probably be nonsense. + + + + <limit> + + + + + + + +<limit> establishes a resource limit. For example: + + <limit name="max_message_size">64</limit> + <limit name="max_completed_connections">512</limit> + + + +The name attribute is mandatory. +Available limit names are: + + "max_incoming_bytes" : total size in bytes of messages + incoming from a single connection + "max_outgoing_bytes" : total size in bytes of messages + queued up for a single connection + "max_message_size" : max size of a single message in + bytes + "service_start_timeout" : milliseconds (thousandths) until + a started service has to connect + "auth_timeout" : milliseconds (thousandths) a + connection is given to + authenticate + "max_completed_connections" : max number of authenticated connections + "max_incomplete_connections" : max number of unauthenticated + connections + "max_connections_per_user" : max number of completed connections from + the same user + "max_pending_service_starts" : max number of service launches in + progress at the same time + "max_names_per_connection" : max number of names a single + connection can own + "max_match_rules_per_connection": max number of match rules for a single + connection + "max_replies_per_connection" : max number of pending method + replies per connection + (number of calls-in-progress) + "reply_timeout" : milliseconds (thousandths) + until a method call times out + + + +The max incoming/outgoing queue sizes allow a new message to be queued +if one byte remains below the max. So you can in fact exceed the max +by max_message_size. + + +max_completed_connections divided by max_connections_per_user is the +number of users that can work together to denial-of-service all other users by using +up all connections on the systemwide bus. + + +Limits are normally only of interest on the systemwide bus, not the user session +buses. + + + + <policy> + + + + + + + +The <policy> element defines a security policy to be applied to a particular +set of connections to the bus. A policy is made up of +<allow> and <deny> elements. Policies are normally used with the systemwide bus; +they are analogous to a firewall in that they allow expected traffic +and prevent unexpected traffic. + + +The <policy> element has one of three attributes: + + context="(default|mandatory)" + user="username or userid" + group="group name or gid" + + + + +Policies are applied to a connection as follows: + + - all context="default" policies are applied + - all group="connection's user's group" policies are applied + in undefined order + - all user="connection's auth user" policies are applied + in undefined order + - all context="mandatory" policies are applied + + + +Policies applied later will override those applied earlier, +when the policies overlap. Multiple policies with the same +user/group/context are applied in the order they appear +in the config file. + + + + <deny> + +<allow> + + + + + +A <deny> element appears below a <policy> element and prohibits some +action. The <allow> element makes an exception to previous <deny> +statements, and works just like <deny> but with the inverse meaning. + + +The possible attributes of these elements are: + + send_interface="interface_name" + send_member="method_or_signal_name" + send_error="error_name" + send_destination="name" + send_type="method_call" | "method_return" | "signal" | "error" + send_path="/path/name" + + receive_interface="interface_name" + receive_member="method_or_signal_name" + receive_error="error_name" + receive_sender="name" + receive_type="method_call" | "method_return" | "signal" | "error" + receive_path="/path/name" + + send_requested_reply="true" | "false" + receive_requested_reply="true" | "false" + + eavesdrop="true" | "false" + + own="name" + own_prefix="name" + user="username" + group="groupname" + + + +Examples: + + <deny send_interface="org.freedesktop.System" send_member="Reboot"/> + <deny receive_interface="org.freedesktop.System" receive_member="Reboot"/> + <deny own="org.freedesktop.System"/> + <deny send_destination="org.freedesktop.System"/> + <deny receive_sender="org.freedesktop.System"/> + <deny user="john"/> + <deny group="enemies"/> + + + +The <deny> element's attributes determine whether the deny "matches" a +particular action. If it matches, the action is denied (unless later +rules in the config file allow it). + + +send_destination and receive_sender rules mean that messages may not be +sent to or received from the *owner* of the given name, not that +they may not be sent *to that name*. That is, if a connection +owns services A, B, C, and sending to A is denied, sending to B or C +will not work either. + + +The other send_* and receive_* attributes are purely textual/by-value +matches against the given field in the message header. + + +"Eavesdropping" occurs when an application receives a message that +was explicitly addressed to a name the application does not own. +Eavesdropping thus only applies to messages that are addressed to +services (i.e. it does not apply to signals). + + +For <allow>, eavesdrop="true" indicates that the rule matches even +when eavesdropping. eavesdrop="false" is the default and means that +the rule only allows messages to go to their specified recipient. +For <deny>, eavesdrop="true" indicates that the rule matches +only when eavesdropping. eavesdrop="false" is the default for <deny> +also, but here it means that the rule applies always, even when +not eavesdropping. The eavesdrop attribute can only be combined with +receive rules (with receive_* attributes). + + + +The [send|receive]_requested_reply attribute works similarly to the eavesdrop +attribute. It controls whether the <deny> or <allow> matches a reply +that is expected (corresponds to a previous method call message). +This attribute only makes sense for reply messages (errors and method +returns), and is ignored for other message types. + + +For <allow>, [send|receive]_requested_reply="true" is the default and indicates that +only requested replies are allowed by the +rule. [send|receive]_requested_reply="false" means that the rule allows any reply +even if unexpected. + + +For <deny>, [send|receive]_requested_reply="false" is the default but indicates that +the rule matches only when the reply was not +requested. [send|receive]_requested_reply="true" indicates that the rule applies +always, regardless of pending reply state. + + +user and group denials mean that the given user or group may +not connect to the message bus. + + +For "name", "username", "groupname", etc. +the character "*" can be substituted, meaning "any." Complex globs +like "foo.bar.*" aren't allowed for now because they'd be work to +implement and maybe encourage sloppy security anyway. + +<allow own_prefix="a.b"/> allows you to own the name "a.b" or any +name whose first dot-separated elements are "a.b": in particular, +you can own "a.b.c" or "a.b.c.d", but not "a.bc" or "a.c". +This is useful when services like Telepathy and ReserveDevice +define a meaning for subtrees of well-known names, such as +org.freedesktop.Telepathy.ConnectionManager.(anything) +and org.freedesktop.ReserveDevice1.(anything). + +It does not make sense to deny a user or group inside a <policy> +for a user or group; user/group denials can only be inside +context="default" or context="mandatory" policies. + + +A single <deny> rule may specify combinations of attributes such as +send_destination and send_interface and send_type. In this case, the +denial applies only if both attributes match the message being denied. +e.g. <deny send_interface="foo.bar" send_destination="foo.blah"/> would +deny messages with the given interface AND the given bus name. +To get an OR effect you specify multiple <deny> rules. + + +You can't include both send_ and receive_ attributes on the same +rule, since "whether the message can be sent" and "whether it can be +received" are evaluated separately. + + +Be careful with send_interface/receive_interface, because the +interface field in messages is optional. + + + + <selinux> + + + + + + + +The <selinux> element contains settings related to Security Enhanced Linux. +More details below. + + + + <associate> + + + + + + + +An <associate> element appears below an <selinux> element and +creates a mapping. Right now only one kind of association is possible: + + <associate own="org.freedesktop.Foobar" context="foo_t"/> + + + +This means that if a connection asks to own the name +"org.freedesktop.Foobar" then the source context will be the context +of the connection and the target context will be "foo_t" - see the +short discussion of SELinux below. + + +Note, the context here is the target context when requesting a name, +NOT the context of the connection owning the name. + + +There's currently no way to set a default for owning any name, if +we add this syntax it will look like: + + <associate own="*" context="foo_t"/> + +If you find a reason this is useful, let the developers know. +Right now the default will be the security context of the bus itself. + + +If two <associate> elements specify the same name, the element +appearing later in the configuration file will be used. + + + +SELinux +See http://www.nsa.gov/selinux/ for full details on SELinux. Some useful excerpts: + + +Every subject (process) and object (e.g. file, socket, IPC object, +etc) in the system is assigned a collection of security attributes, +known as a security context. A security context contains all of the +security attributes associated with a particular subject or object +that are relevant to the security policy. + + +In order to better encapsulate security contexts and to provide +greater efficiency, the policy enforcement code of SELinux typically +handles security identifiers (SIDs) rather than security contexts. A +SID is an integer that is mapped by the security server to a security +context at runtime. + + +When a security decision is required, the policy enforcement code +passes a pair of SIDs (typically the SID of a subject and the SID of +an object, but sometimes a pair of subject SIDs or a pair of object +SIDs), and an object security class to the security server. The object +security class indicates the kind of object, e.g. a process, a regular +file, a directory, a TCP socket, etc. + + +Access decisions specify whether or not a permission is granted for a +given pair of SIDs and class. Each object class has a set of +associated permissions defined to control operations on objects with +that class. + + +D-Bus performs SELinux security checks in two places. + + +First, any time a message is routed from one connection to another +connection, the bus daemon will check permissions with the security context of +the first connection as source, security context of the second connection +as target, object class "dbus" and requested permission "send_msg". + + +If a security context is not available for a connection +(impossible when using UNIX domain sockets), then the target +context used is the context of the bus daemon itself. +There is currently no way to change this default, because we're +assuming that only UNIX domain sockets will be used to +connect to the systemwide bus. If this changes, we'll +probably add a way to set the default connection context. + + +Second, any time a connection asks to own a name, +the bus daemon will check permissions with the security +context of the connection as source, the security context specified +for the name in the config file as target, object +class "dbus" and requested permission "acquire_svc". + + +The security context for a bus name is specified with the +<associate> element described earlier in this document. +If a name has no security context associated in the +configuration file, the security context of the bus daemon +itself will be used. + + + +AUTHOR +See http://www.freedesktop.org/software/dbus/doc/AUTHORS + + + +BUGS +Please send bug reports to the D-Bus mailing list or bug tracker, +see http://www.freedesktop.org/software/dbus/ + + + diff --git a/doc/dbus-launch.1.xml b/doc/dbus-launch.1.xml new file mode 100644 index 0000000..ab4d5ed --- /dev/null +++ b/doc/dbus-launch.1.xml @@ -0,0 +1,270 @@ + + + + + + + + +dbus-launch +1 + + +dbus-launch +Utility to start a message bus from a shell script + + + + + dbus-launch --version + --sh-syntax + --csh-syntax + --auto-syntax + --exit-with-session + --autolaunch=MACHINEID + --config-file=FILENAME + PROGRAM + ARGS + + + + + +DESCRIPTION +The dbus-launch command is used to start a session bus +instance of dbus-daemon from a shell script. +It would normally be called from a user's login +scripts. Unlike the daemon itself, dbus-launch exits, so +backticks or the $() construct can be used to read information from +dbus-launch. + +With no arguments, dbus-launch will launch a session bus +instance and print the address and PID of that instance to standard +output. + +You may specify a program to be run; in this case, dbus-launch +will launch a session bus instance, set the appropriate environment +variables so the specified program can find the bus, and then execute the +specified program, with the specified arguments. See below for +examples. + +If you launch a program, dbus-launch will not print the +information about the new bus to standard output. + +When dbus-launch prints bus information to standard output, by +default it is in a simple key-value pairs format. However, you may +request several alternate syntaxes using the --sh-syntax, --csh-syntax, +--binary-syntax, or +--auto-syntax options. Several of these cause dbus-launch to emit shell code +to set up the environment. + +With the --auto-syntax option, dbus-launch looks at the value +of the SHELL environment variable to determine which shell syntax +should be used. If SHELL ends in "csh", then csh-compatible code is +emitted; otherwise Bourne shell code is emitted. Instead of passing +--auto-syntax, you may explicitly specify a particular one by using +--sh-syntax for Bourne syntax, or --csh-syntax for csh syntax. +In scripts, it's more robust to avoid --auto-syntax and you hopefully +know which shell your script is written in. + + +See http://www.freedesktop.org/software/dbus/ for more information +about D-Bus. See also the man page for dbus-daemon. + + + +EXAMPLES +Distributions running +dbus-launch +as part of a standard X session should run +dbus-launch --exit-with-session +after the X server has started and become available, as a wrapper around +the "main" X client (typically a session manager or window manager), as in +these examples: + +
+dbus-launch --exit-with-session gnome-session + +dbus-launch --exit-with-session openbox + +dbus-launch --exit-with-session ~/.xsession +
+ +If your distribution does not do this, you can achieve similar results +by running your session or window manager in the same way in a script +run by your X session, such as +~/.xsession, +~/.xinitrc +or +~/.Xclients. + +To start a D-Bus session within a text-mode session, you can run +dbus-launch in the background. For instance, in a sh-compatible shell: + + + ## test for an existing bus daemon, just to be safe + if test -z "$DBUS_SESSION_BUS_ADDRESS" ; then + ## if not found, launch a new one + eval `dbus-launch --sh-syntax` + echo "D-Bus per-session daemon address is: $DBUS_SESSION_BUS_ADDRESS" + fi + +Note that in this case, dbus-launch will exit, and dbus-daemon will not be +terminated automatically on logout. + + + +AUTOMATIC LAUNCHING +If DBUS_SESSION_BUS_ADDRESS is not set for a process that tries to use +D-Bus, by default the process will attempt to invoke dbus-launch with +the --autolaunch option to start up a new session bus or find the +existing bus address on the X display or in a file in +~/.dbus/session-bus/ + + +Whenever an autolaunch occurs, the application that had to +start a new bus will be in its own little world; it can effectively +end up starting a whole new session if it tries to use a lot of +bus services. This can be suboptimal or even totally broken, depending +on the app and what it tries to do. + + +There are two common reasons for autolaunch. One is ssh to a remote +machine. The ideal fix for that would be forwarding of +DBUS_SESSION_BUS_ADDRESS in the same way that DISPLAY is forwarded. +In the meantime, you can edit the session.conf config file to +have your session bus listen on TCP, and manually set +DBUS_SESSION_BUS_ADDRESS, if you like. + + +The second common reason for autolaunch is an su to another user, and +display of X applications running as the second user on the display +belonging to the first user. Perhaps the ideal fix in this case +would be to allow the second user to connect to the session bus of the +first user, just as they can connect to the first user's display. +However, a mechanism for that has not been coded. + + +You can always avoid autolaunch by manually setting +DBUS_SESSION_BUS_ADDRESS. Autolaunch happens because the default +address if none is set is "autolaunch:", so if any other address is +set there will be no autolaunch. You can however include autolaunch in +an explicit session bus address as a fallback, for example +DBUS_SESSION_BUS_ADDRESS="something:,autolaunch:" - in that case if +the first address doesn't work, processes will autolaunch. (The bus +address variable contains a comma-separated list of addresses to try.) + + +The --autolaunch option is considered an internal implementation +detail of libdbus, and in fact there are plans to change it. There's +no real reason to use it outside of the libdbus implementation anyhow. + + + +OPTIONS +The following options are supported: + + + + +Choose --csh-syntax or --sh-syntax based on the SHELL environment variable. + + +Write to stdout a nul-terminated bus address, then the bus PID as a +binary integer of size sizeof(pid_t), then the bus X window ID as a +binary integer of size sizeof(long). Integers are in the machine's +byte order, not network byte order or any other canonical byte order. + + + + + + +Close the standard error output stream before starting the D-Bus +daemon. This is useful if you want to capture dbus-launch error +messages but you don't want dbus-daemon to keep the stream open to +your application. + + + + + + +Pass --config-file=FILENAME to the bus daemon, instead of passing it +the --session argument. See the man page for dbus-daemon + + + + + + +Emit csh compatible code to set up environment variables. + + + + + + +If this option is provided, a persistent "babysitter" process will be +created that watches stdin for HUP and tries to connect to the X +server. If this process gets a HUP on stdin or loses its X connection, +it kills the message bus daemon. + + + + + + +This option implies that dbus-launch should scan for a +previously-started session and reuse the values found there. If no +session is found, it will start a new session. The +--exit-with-session option is implied if --autolaunch is given. +This option is for the exclusive use of libdbus, you do not want to +use it manually. It may change in the future. + + + + + + +Emit Bourne-shell compatible code to set up environment variables. + + + + + + +Print the version of dbus-launch + + + + + + +NOTES +If you run +dbus-launch myapp +(with any other options), dbus-daemon will +not +exit when +myapp +terminates: this is because +myapp +is assumed to be part of a larger session, rather than a session in its +own right. + + + +AUTHOR +See http://www.freedesktop.org/software/dbus/doc/AUTHORS + + + +BUGS +Please send bug reports to the D-Bus mailing list or bug tracker, +see http://www.freedesktop.org/software/dbus/ + + + diff --git a/doc/dbus-launch.xml b/doc/dbus-launch.xml new file mode 100644 index 0000000..dc34898 --- /dev/null +++ b/doc/dbus-launch.xml @@ -0,0 +1,240 @@ + + + + + + + + + +dbus-launch +1 + + +dbus-launch +Utility to start a message bus from a shell script + + + + + dbus-launch --version + --sh-syntax + --csh-syntax + --auto-syntax + --exit-with-session + --autolaunch=MACHINEID + --config-file=FILENAME + PROGRAM + ARGS + + + + + +DESCRIPTION +The dbus-launch command is used to start a session bus +instance of dbus-daemon from a shell script. +It would normally be called from a user's login +scripts. Unlike the daemon itself, dbus-launch exits, so +backticks or the $() construct can be used to read information from +dbus-launch. + +With no arguments, dbus-launch will launch a session bus +instance and print the address and pid of that instance to standard +output. + +You may specify a program to be run; in this case, dbus-launch +will launch a session bus instance, set the appropriate environment +variables so the specified program can find the bus, and then execute the +specified program, with the specified arguments. See below for +examples. + +If you launch a program, dbus-launch will not print the +information about the new bus to standard output. + +When dbus-launch prints bus information to standard output, by +default it is in a simple key-value pairs format. However, you may +request several alternate syntaxes using the --sh-syntax, --csh-syntax, +--binary-syntax, or +--auto-syntax options. Several of these cause dbus-launch to emit shell code +to set up the environment. + +With the --auto-syntax option, dbus-launch looks at the value +of the SHELL environment variable to determine which shell syntax +should be used. If SHELL ends in "csh", then csh-compatible code is +emitted; otherwise Bourne shell code is emitted. Instead of passing +--auto-syntax, you may explicity specify a particular one by using +--sh-syntax for Bourne syntax, or --csh-syntax for csh syntax. +In scripts, it's more robust to avoid --auto-syntax and you hopefully +know which shell your script is written in. + + +See http://www.freedesktop.org/software/dbus/ for more information +about D-Bus. See also the man page for dbus-daemon. + + +Here is an example of how to use dbus-launch with an +sh-compatible shell to start the per-session bus daemon: + + + ## test for an existing bus daemon, just to be safe + if test -z "$DBUS_SESSION_BUS_ADDRESS" ; then + ## if not found, launch a new one + eval `dbus-launch --sh-syntax --exit-with-session` + echo "D-Bus per-session daemon address is: $DBUS_SESSION_BUS_ADDRESS" + fi + + +You might run something like that in your login scripts. + + +Another way to use dbus-launch is to run your main session +program, like so: + + +dbus-launch gnome-session + + +The above would likely be appropriate for ~/.xsession or ~/.Xclients. + + + +AUTOMATIC LAUNCHING +If DBUS_SESSION_BUS_ADDRESS is not set for a process that tries to use +D-Bus, by default the process will attempt to invoke dbus-launch with +the --autolaunch option to start up a new session bus or find the +existing bus address on the X display or in a file in +~/.dbus/session-bus/ + + +Whenever an autolaunch occurs, the application that had to +start a new bus will be in its own little world; it can effectively +end up starting a whole new session if it tries to use a lot of +bus services. This can be suboptimal or even totally broken, depending +on the app and what it tries to do. + + +There are two common reasons for autolaunch. One is ssh to a remote +machine. The ideal fix for that would be forwarding of +DBUS_SESSION_BUS_ADDRESS in the same way that DISPLAY is forwarded. +In the meantime, you can edit the session.conf config file to +have your session bus listen on TCP, and manually set +DBUS_SESSION_BUS_ADDRESS, if you like. + + +The second common reason for autolaunch is an su to another user, and +display of X applications running as the second user on the display +belonging to the first user. Perhaps the ideal fix in this case +would be to allow the second user to connect to the session bus of the +first user, just as they can connect to the first user's display. +However, a mechanism for that has not been coded. + + +You can always avoid autolaunch by manually setting +DBUS_SESSION_BUS_ADDRESS. Autolaunch happens because the default +address if none is set is "autolaunch:", so if any other address is +set there will be no autolaunch. You can however include autolaunch in +an explicit session bus address as a fallback, for example +DBUS_SESSION_BUS_ADDRESS="something:,autolaunch:" - in that case if +the first address doesn't work, processes will autolaunch. (The bus +address variable contains a comma-separated list of addresses to try.) + + +The --autolaunch option is considered an internal implementation +detail of libdbus, and in fact there are plans to change it. There's +no real reason to use it outside of the libdbus implementation anyhow. + + + +OPTIONS +The following options are supported: + + + + +Choose --csh-syntax or --sh-syntax based on the SHELL environment variable. + + +Write to stdout a nul-terminated bus address, then the bus PID as a +binary integer of size sizeof(pid_t), then the bus X window ID as a +binary integer of size sizeof(long). Integers are in the machine's +byte order, not network byte order or any other canonical byte order. + + + + + + +Close the standard error output stream before starting the D-Bus +daemon. This is useful if you want to capture dbus-launch error +messages but you don't want dbus-daemon to keep the stream open to +your application. + + + + + + +Pass --config-file=FILENAME to the bus daemon, instead of passing it +the --session argument. See the man page for dbus-daemon + + + + + + +Emit csh compatible code to set up environment variables. + + + + + + +If this option is provided, a persistent "babysitter" process will be +created that watches stdin for HUP and tries to connect to the X +server. If this process gets a HUP on stdin or loses its X connection, +it kills the message bus daemon. + + + + + + +This option implies that dbus-launch should scan for a +previously-started session and reuse the values found there. If no +session is found, it will start a new session. The +--exit-with-session option is implied if --autolaunch is given. +This option is for the exclusive use of libdbus, you do not want to +use it manually. It may change in the future. + + + + + + +Emit Bourne-shell compatible code to set up environment variables. + + + + + + +Print the version of dbus-launch + + + + + + +AUTHOR +See http://www.freedesktop.org/software/dbus/doc/AUTHORS + + + +BUGS +Please send bug reports to the D-Bus mailing list or bug tracker, +see http://www.freedesktop.org/software/dbus/ + + + diff --git a/doc/dbus-monitor.1.xml b/doc/dbus-monitor.1.xml new file mode 100644 index 0000000..20e9301 --- /dev/null +++ b/doc/dbus-monitor.1.xml @@ -0,0 +1,121 @@ + + + + + + + + +dbus-monitor +1 + + +dbus-monitor +debug probe to print message bus messages + + + + + dbus-monitor + --system --session --address ADDRESS + --profile --monitor + watchexpressions + + + + + +DESCRIPTION +The dbus-monitor command is used to monitor messages going +through a D-Bus message bus. See +http://www.freedesktop.org/software/dbus/ for more information about +the big picture. + + +There are two well-known message buses: the systemwide message bus +(installed on many systems as the "messagebus" service) and the +per-user-login-session message bus (started each time a user logs in). +The --system and --session options direct dbus-monitor to +monitor the system or session buses respectively. If neither is +specified, dbus-monitor monitors the session bus. + + +dbus-monitor has two different output modes, the 'classic'-style +monitoring mode and profiling mode. The profiling format is a compact +format with a single line per message and microsecond-resolution timing +information. The --profile and --monitor options select the profiling +and monitoring output format respectively. If neither is specified, +dbus-monitor uses the monitoring output format. + + +In order to get dbus-monitor to see the messages you are interested +in, you should specify a set of watch expressions as you would expect to +be passed to the dbus_bus_add_match function. + + +The message bus configuration may keep dbus-monitor from seeing +all messages, especially if you run the monitor as a non-root user. + + + +OPTIONS + + + + +Monitor the system message bus. + + + + + +Monitor the session message bus. (This is the default.) + + + + + +Monitor an arbitrary message bus given at ADDRESS. + + + + + +Use the profiling output format. + + + + + +Use the monitoring output format. (This is the default.) + + + + + + +EXAMPLE +Here is an example of using dbus-monitor to watch for the gnome typing +monitor to say things + + + dbus-monitor "type='signal',sender='org.gnome.TypingMonitor',interface='org.gnome.TypingMonitor'" + + + + + +AUTHOR +dbus-monitor was written by Philip Blundell. +The profiling output mode was added by Olli Salli. + + + +BUGS +Please send bug reports to the D-Bus mailing list or bug tracker, +see http://www.freedesktop.org/software/dbus/ + + + diff --git a/doc/dbus-monitor.xml b/doc/dbus-monitor.xml new file mode 100644 index 0000000..b41cace --- /dev/null +++ b/doc/dbus-monitor.xml @@ -0,0 +1,121 @@ + + + + + + + + + +dbus-monitor +1 + + +dbus-monitor +debug probe to print message bus messages + + + + + dbus-monitor + --system --session --address ADDRESS + --profile --monitor + watchexpressions + + + + + +DESCRIPTION +The dbus-monitor command is used to monitor messages going +through a D-Bus message bus. See +http://www.freedesktop.org/software/dbus/ for more information about +the big picture. + + +There are two well-known message buses: the systemwide message bus +(installed on many systems as the "messagebus" service) and the +per-user-login-session message bus (started each time a user logs in). +The --system and --session options direct dbus-monitor to +monitor the system or session buses respectively. If neither is +specified, dbus-monitor monitors the session bus. + + +dbus-monitor has two different output modes, the 'classic'-style +monitoring mode and profiling mode. The profiling format is a compact +format with a single line per message and microsecond-resolution timing +information. The --profile and --monitor options select the profiling +and monitoring output format respectively. If neither is specified, +dbus-monitor uses the monitoring output format. + + +In order to get dbus-monitor to see the messages you are interested +in, you should specify a set of watch expressions as you would expect to +be passed to the dbus_bus_add_match function. + + +The message bus configuration may keep dbus-monitor from seeing +all messages, especially if you run the monitor as a non-root user. + + + +OPTIONS + + + + +Monitor the system message bus. + + + + + +Monitor the session message bus. (This is the default.) + + + + + +Monitor an arbitrary message bus given at ADDRESS. + + + + + +Use the profiling output format. + + + + + +Use the monitoring output format. (This is the default.) + + + + + + +EXAMPLE +Here is an example of using dbus-monitor to watch for the gnome typing +monitor to say things + + + dbus-monitor "type='signal',sender='org.gnome.TypingMonitor',interface='org.gnome.TypingMonitor'" + + + + + +AUTHOR +dbus-monitor was written by Philip Blundell. +The profiling output mode was added by Olli Salli. + + + +BUGS +Please send bug reports to the D-Bus mailing list or bug tracker, +see http://www.freedesktop.org/software/dbus/ + + + diff --git a/doc/dbus-send.1.xml b/doc/dbus-send.1.xml new file mode 100644 index 0000000..30d57c5 --- /dev/null +++ b/doc/dbus-send.1.xml @@ -0,0 +1,157 @@ + + + + + + + + +dbus-send +1 + + +dbus-send +Send a message to a message bus + + + + + dbus-send + --system --session + --dest=NAME + --print-reply =literal + --reply-timeout=MSEC + --type=TYPE + OBJECT_PATH + INTERFACE.MEMBER + CONTENTS + + + + + +DESCRIPTION +The dbus-send command is used to send a message to a D-Bus message +bus. See http://www.freedesktop.org/software/dbus/ for more +information about the big picture. + + +There are two well-known message buses: the systemwide message bus +(installed on many systems as the "messagebus" service) and the +per-user-login-session message bus (started each time a user logs in). +The and options direct +dbus-send to send messages to the system or session buses respectively. +If neither is specified, dbus-send sends to the session bus. + + +Nearly all uses of dbus-send must provide the argument +which is the name of a connection on the bus to send the message to. If + is omitted, no destination is set. + + +The object path and the name of the message to send must always be +specified. Following arguments, if any, are the message contents +(message arguments). These are given as type-specified values and +may include containers (arrays, dicts, and variants) as described below. + + +<contents> ::= <item> | <container> [ <item> | <container>...] +<item> ::= <type>:<value> +<container> ::= <array> | <dict> | <variant> +<array> ::= array:<type>:<value>[,<value>...] +<dict> ::= dict:<type>:<type>:<key>,<value>[,<key>,<value>...] +<variant> ::= variant:<type>:<value> +<type> ::= string | int16 | uint 16 | int32 | uint32 | int64 | uint64 | double | byte | boolean | objpath + + +D-Bus supports more types than these, but dbus-send currently +does not. Also, dbus-send does not permit empty containers +or nested containers (e.g. arrays of variants). + + +Here is an example invocation: + + + dbus-send --dest=org.freedesktop.ExampleName \ + /org/freedesktop/sample/object/name \ + org.freedesktop.ExampleInterface.ExampleMethod \ + int32:47 string:'hello world' double:65.32 \ + array:string:"1st item","next item","last item" \ + dict:string:int32:"one",1,"two",2,"three",3 \ + variant:int32:-8 \ + objpath:/org/freedesktop/sample/object/name + + + +Note that the interface is separated from a method or signal +name by a dot, though in the actual protocol the interface +and the interface member are separate fields. + + + +OPTIONS +The following options are supported: + + + NAME + +Specify the name of the connection to receive the message. + + + + + +Block for a reply to the message sent, and print any reply received +in a human-readable form. + + + + + +Block for a reply to the message sent, and print the body of the +reply. If the reply is an object path or a string, it is printed +literally, with no punctuation, escape characters etc. + + + + MSEC + +Wait for a reply for up to MSEC milliseconds. +The default is implementation‐defined, typically 25 seconds. + + + + + +Send to the system message bus. + + + + + +Send to the session message bus. (This is the default.) + + + + TYPE + +Specify method_call or signal (defaults to "signal"). + + + + + + +AUTHOR +dbus-send was written by Philip Blundell. + + + +BUGS +Please send bug reports to the D-Bus mailing list or bug tracker, +see http://www.freedesktop.org/software/dbus/ + + + diff --git a/doc/dbus-send.xml b/doc/dbus-send.xml new file mode 100644 index 0000000..7fefc03 --- /dev/null +++ b/doc/dbus-send.xml @@ -0,0 +1,143 @@ + + + + + + + + + +dbus-send +1 + + +dbus-send +Send a message to a message bus + + + + + dbus-send + --system --session + --dest=NAME + --print-reply + --type=TYPE + <destination + object + path> + <message + name> + contents + + + + + +DESCRIPTION +The dbus-send command is used to send a message to a D-Bus message +bus. See http://www.freedesktop.org/software/dbus/ for more +information about the big picture. + + +There are two well-known message buses: the systemwide message bus +(installed on many systems as the "messagebus" service) and the +per-user-login-session message bus (started each time a user logs in). +The --system and --session options direct dbus-send to send +messages to the system or session buses respectively. If neither is +specified, dbus-send sends to the session bus. + + +Nearly all uses of dbus-send must provide the --dest argument +which is the name of a connection on the bus to send the message to. If +--dest is omitted, no destination is set. + + +The object path and the name of the message to send must always be +specified. Following arguments, if any, are the message contents +(message arguments). These are given as type-specified values and +may include containers (arrays, dicts, and variants) as described below. + + +<contents> ::= <item> | <container> [ <item> | <container>...] +<item> ::= <type>:<value> +<container> ::= <array> | <dict> | <variant> +<array> ::= array:<type>:<value>[,<value>...] +<dict> ::= dict:<type>:<type>:<key>,<value>[,<key>,<value>...] +<variant> ::= variant:<type>:<value> +<type> ::= string | int16 | uint 16 | int32 | uint32 | int64 | uint64 | double | byte | boolean | objpath + + +D-Bus supports more types than these, but dbus-send currently +does not. Also, dbus-send does not permit empty containers +or nested containers (e.g. arrays of variants). + + +Here is an example invocation: + + + dbus-send --dest=org.freedesktop.ExampleName \ + /org/freedesktop/sample/object/name \ + org.freedesktop.ExampleInterface.ExampleMethod \ + int32:47 string:'hello world' double:65.32 \ + array:string:"1st item","next item","last item" \ + dict:string:int32:"one",1,"two",2,"three",3 \ + variant:int32:-8 \ + objpath:/org/freedesktop/sample/object/name + + + +Note that the interface is separated from a method or signal +name by a dot, though in the actual protocol the interface +and the interface member are separate fields. + + + +OPTIONS +The following options are supported: + + + + +Specify the name of the connection to receive the message. + + + + + +Block for a reply to the message sent, and print any reply received. + + + + + +Send to the system message bus. + + + + + +Send to the session message bus. (This is the default.) + + + + + +Specify "method_call" or "signal" (defaults to "signal"). + + + + + + +AUTHOR +dbus-send was written by Philip Blundell. + + + +BUGS +Please send bug reports to the D-Bus mailing list or bug tracker, +see http://www.freedesktop.org/software/dbus/ + + + diff --git a/doc/dbus-uuidgen.1.xml b/doc/dbus-uuidgen.1.xml new file mode 100644 index 0000000..3d99ef8 --- /dev/null +++ b/doc/dbus-uuidgen.1.xml @@ -0,0 +1,125 @@ + + + + + + + + +dbus-uuidgen +1 + + +dbus-uuidgen +Utility to generate UUIDs + + + + + dbus-uuidgen --version + --ensure =FILENAME + --get =FILENAME + + + + + +DESCRIPTION +The dbus-uuidgen command generates or reads a universally unique ID. + + +Note that the D-Bus UUID has no relationship to RFC 4122 and does not generate +UUIDs compatible with that spec. Many systems have a separate command +for that (often called "uuidgen"). + + +See http://www.freedesktop.org/software/dbus/ for more information +about D-Bus. + + +The primary usage of dbus-uuidgen is to run in the post-install +script of a D-Bus package like this: + + dbus-uuidgen --ensure + + + +This will ensure that /var/lib/dbus/machine-id exists and has the uuid in it. +It won't overwrite an existing uuid, since this id should remain fixed +for a single machine until the next reboot at least. + + +The important properties of the machine UUID are that 1) it remains +unchanged until the next reboot and 2) it is different for any two +running instances of the OS kernel. That is, if two processes see the +same UUID, they should also see the same shared memory, UNIX domain +sockets, local X displays, localhost.localdomain resolution, process +IDs, and so forth. + + +If you run dbus-uuidgen with no options it just prints a new uuid made +up out of thin air. + + +If you run it with --get, it prints the machine UUID by default, or +the UUID in the specified file if you specify a file. + + +If you try to change an existing machine-id on a running system, it will +probably result in bad things happening. Don't try to change this file. Also, +don't make it the same on two different systems; it needs to be different +anytime there are two different kernels running. + + +The UUID should be different on two different virtual machines, +because there are two different kernels. + + + +OPTIONS +The following options are supported: + + + + +If a filename is not given, defaults to localstatedir/lib/dbus/machine-id +(localstatedir is usually /var). If this file exists and is valid, the +uuid in the file is printed on stdout. Otherwise, the command exits +with a nonzero status. + + + + + + +If a filename is not given, defaults to localstatedir/lib/dbus/machine-id +(localstatedir is usually /var). If this file exists then it will be +validated, and a failure code returned if it contains the wrong thing. +If the file does not exist, it will be created with a new uuid in it. +On success, prints no output. + + + + + + +Print the version of dbus-uuidgen + + + + + + +AUTHOR +See http://www.freedesktop.org/software/dbus/doc/AUTHORS + + + +BUGS +Please send bug reports to the D-Bus mailing list or bug tracker, +see http://www.freedesktop.org/software/dbus/ + + + -- 1.7.10.4