.PP
.B dbus-daemon-1
dbus-daemon-1 [\-\-version] [\-\-session] [\-\-system] [\-\-config-file=FILE]
-[\-\-print-address[=DESCRIPTOR]]
+[\-\-print-address[=DESCRIPTOR]] [\-\-print-pid[=DESCRIPTOR]] [\-\-fork]
.SH DESCRIPTION
.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.
.PP
If present, the bus daemon becomes a real daemon (forks
-into the background, etc.).
+into the background, etc.). This is generally used
+rather than the \-\-fork command line option.
.TP
.I "<listen>"
progress at the same time
"max_services_per_connection": max number of services a single
connection can own
+ "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
.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
-A <deny> element appears below a <policy> element and prohibits
-some action. The possible attributes of a <deny> element are:
+The possible attributes of these elements are:
.nf
- send="messagename"
- receive="messagename"
+ send_interface="interface_name"
+ send_member="method_or_signal_name"
+ send_error="error_name"
+ send_destination="service_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="service_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="servicename"
- send_to="servicename"
- receive_from="servicename"
user="username"
group="groupname"
.fi
.PP
Examples:
.nf
- <deny send="org.freedesktop.System.Reboot"/>
- <deny receive="org.freedesktop.System.Reboot"/>
+ <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_to="org.freedesktop.System"/>
- <deny receive_from="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> attributes determine whether the deny "matches" a
+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_to and receive_from mean that messages may not be sent to or
-received from the *owner* of the given service, not that they may not
-be sent *to that service 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.
+send_destination and receive_sender rules mean that messages may not be
+sent to or received from the *owner* of the given service, not that
+they may not be sent *to that service 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 service the application does not own.
+Eavesdropping thus only applies to messages that are addressed to
+services (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
+receive rules (with 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 "servicename" or "messagename" or "username" or "groupname"
+For "service_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.
context="default" or context="mandatory" policies.
.PP
-A single <deny> rule may specify both send and send_to, OR both
-receive and receive_from. In this case, the denial applies only if
-both attributes match the message being denied.
-e.g. <deny send="foo.bar" send_to="foo.blah"/> would deny
-messages of the given name AND to the given service.
+A single <deny> rule may specify combinations of attributes such as
+send_service 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_service="foo.blah"/> would
+deny messages of the given interface AND to the given service.
+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.
.TP
-.I "<allow>"
+.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 service
+"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 acquiring a service,
+NOT the context of the connection owning the service.
+
+.PP
+There's currently no way to set a default for owning any service, 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 service 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 service,
+the bus daemon will check permissions with the security
+context of the connection as source, the security context specified
+for the service name with an <associate> element as target, object
+class "dbus" and requested permission "acquire_svc".
.PP
-Makes an exception to previous <deny> statements. Works
-just like <deny> but with the inverse meaning.
+If the service name has no security context associated in the
+configuration file, the security context of the bus daemon
+itself will be used.
.SH AUTHOR
See http://www.freedesktop.org/software/dbus/doc/AUTHORS
projects / platform / upstream / dbus.git / blobdiff