diff options
Diffstat (limited to 'bus/dbus-daemon.1.in')
| -rw-r--r-- | bus/dbus-daemon.1.in | 760 |
1 files changed, 760 insertions, 0 deletions
diff --git a/bus/dbus-daemon.1.in b/bus/dbus-daemon.1.in new file mode 100644 index 00000000..8342600e --- /dev/null +++ b/bus/dbus-daemon.1.in @@ -0,0 +1,760 @@ +.\" +.\" dbus-daemon manual page. +.\" Copyright (C) 2003,2008 Red Hat, Inc. +.\" +.TH dbus-daemon 1 +.SH NAME +dbus-daemon \- Message bus daemon +.SH SYNOPSIS +.PP +.B dbus-daemon +dbus-daemon [\-\-version] [\-\-session] [\-\-system] [\-\-config-file=FILE] +[\-\-print-address[=DESCRIPTOR]] [\-\-print-pid[=DESCRIPTOR]] [\-\-fork] + +.SH DESCRIPTION + +\fIdbus-daemon\fP 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; \fIdbus-daemon\fP 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. + +.PP +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). +\fIdbus-daemon\fP is used for both of these instances, but with +a different configuration file. + +.PP +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. + +.PP +The systemwide daemon is normally launched by an init script, +standardly called simply "messagebus". + +.PP +The systemwide daemon is largely used for broadcasting system events, +such as changes to the printer queue, or adding/removing devices. + +.PP +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). + +.PP +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. + +.SH OPTIONS +The following options are supported: +.TP +.I "--config-file=FILE" +Use the given configuration file. +.TP +.I "--fork" +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. +.TP +.I "--print-address[=DESCRIPTOR]" +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. +.TP +.I "--print-pid[=DESCRIPTOR]" +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. +.TP +.I "--session" +Use the standard configuration file for the per-login-session message +bus. +.TP +.I "--system" +Use the standard configuration file for the systemwide message bus. +.TP +.I "--version" +Print the version of the daemon. + +.SH 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. + +.PP +The configuration file also establishes resource limits, security +parameters, and so forth. + +.PP +The configuration file is not part of any interoperability +specification and its backward compatibility is not guaranteed; this +document is documentation, not specification. + +.PP +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. + +.PP +The configuration file is an XML document. It must have the following +doctype declaration: +.nf + + <!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-Bus Bus Configuration 1.0//EN" + "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd"> + +.fi + +.PP +The following elements may be present in the configuration file. + +.TP +.I "<busconfig>" + +.PP +Root element. + +.TP +.I "<type>" + +.PP +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. + +.PP +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). + +.PP +Example: <type>session</type> + +.TP +.I "<include>" + +.PP +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. + +.PP +<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. + +.TP +.I "<includedir>" + +.PP +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. + +.PP +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. + +.TP +.I "<user>" + +.PP +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. + +.PP +The last <user> entry in the file "wins", the others are ignored. + +.PP +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. + +.TP +.I "<fork>" + +.PP +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. + +.TP +.I "<keep_umask>" + +.PP +If present, the bus daemon keeps its original umask when forking. +This may be useful to avoid affecting the behavior of child processes. + +.TP +.I "<listen>" + +.PP +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. + +.PP +Example: <listen>unix:path=/tmp/foo</listen> + +.PP +Example: <listen>tcp:host=localhost,port=1234</listen> + +.PP +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. + +.PP +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 + +.PP +Example: <listen>tcp:host=localhost,port=0,family=ipv4</listen> + +.PP +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. + +.PP +Example: <listen>tcp:host=localhost,port=0</listen> + +.PP +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. + +.PP +Example: <listen>tcp:host=localhost,bind=*,port=0</listen> + +.TP +.I "<auth>" + +.PP +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. + +.PP +Example: <auth>EXTERNAL</auth> + +.PP +Example: <auth>DBUS_COOKIE_SHA1</auth> + +.TP +.I "<servicedir>" + +.PP +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). + +.PP +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. + +.TP +.I "<standard_session_servicedirs/>" + +.PP +<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. + +.PP +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. + +.PP +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. + +.TP +.I "<standard_system_servicedirs/>" + +.PP +<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. + +.PP +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. + +.TP +.I "<servicehelper/>" + +.PP +<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. + +.PP +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. + +.TP +.I "<limit>" + +.PP +<limit> establishes a resource limit. For example: +.nf + <limit name="max_message_size">64</limit> + <limit name="max_completed_connections">512</limit> +.fi + +.PP +The name attribute is mandatory. +Available limit names are: +.nf + "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 +.fi + +.PP +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. + +.PP +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. + +.PP +Limits are normally only of interest on the systemwide bus, not the user session +buses. + +.TP +.I "<policy>" + +.PP +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. + +.PP +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. + +.PP +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. + +.PP +The <policy> element has one of four attributes: +daemon.1.in +.nf + context="(default|mandatory)" + at_console="(true|false)" + user="username or userid" + group="group name or gid" +.fi + +.PP +Policies are applied to a connection as follows: +.nf + - 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 +.fi + +.PP +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. + +.TP +.I "<deny>" +.I "<allow>" + +.PP +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. + +.PP +The possible attributes of these elements are: +.nf + 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" + user="username" + group="groupname" +.fi + +.PP +Examples: +.nf + <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"/> +.fi + +.PP +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). + +.PP +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. + +.PP +The other send_* and receive_* attributes are purely textual/by-value +matches against the given field in the message header. + +.PP +"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). + +.PP +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). + + +.PP +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. + +.PP +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. + +.PP +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. + +.PP +user and group denials mean that the given user or group may +not connect to the message bus. + +.PP +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. + +.PP +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. + +.PP +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. + +.PP +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. + +.PP +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"/> + +.TP +.I "<selinux>" + +.PP +The <selinux> element contains settings related to Security Enhanced Linux. +More details below. + +.TP +.I "<associate>" + +.PP +An <associate> element appears below an <selinux> element and +creates a mapping. Right now only one kind of association is possible: +.nf + <associate own="org.freedesktop.Foobar" context="foo_t"/> +.fi + +.PP +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. + +.PP +Note, the context here is the target context when requesting a name, +NOT the context of the connection owning the name. + +.PP +There's currently no way to set a default for owning any name, if +we add this syntax it will look like: +.nf + <associate own="*" context="foo_t"/> +.fi +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. + +.PP +If two <associate> elements specify the same name, the element +appearing later in the configuration file will be used. + +.SH SELinux + +.PP +See http://www.nsa.gov/selinux/ for full details on SELinux. Some useful excerpts: + +.IP "" 8 +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. + +.IP "" 8 +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. + +.IP "" 8 +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. + +.IP "" 8 +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. + +.PP +D-Bus performs SELinux security checks in two places. + +.PP +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". + +.PP +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. + +.PP +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". + +.PP +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. + +.SH DEBUGGING + +.PP +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. + +.PP +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. + +.PP +The simplest way to figure out what's happening on the bus is to run +the \fIdbus-monitor\fP program, which comes with the D-Bus +package. You can also send test messages with \fIdbus-send\fP. These +programs have their own man pages. + +.PP +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. + +.PP +To run a separate test copy of the daemon, for example you might open a terminal +and type: +.nf + DBUS_VERBOSE=1 dbus-daemon --session --print-address +.fi + +.PP +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. + +.PP +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.) + +.PP +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. + + +.SH AUTHOR +See http://www.freedesktop.org/software/dbus/doc/AUTHORS + +.SH BUGS +Please send bug reports to the D-Bus mailing list or bug tracker, +see http://www.freedesktop.org/software/dbus/ |