Merge branch 'dbus-1.2'
[platform/upstream/dbus.git] / cmake / bus / dbus-daemon.xml
1 <?xml version="1.0" encoding="ISO-8859-1"?>
2 <!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
3                    "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd">
4 <!-- lifted from troff+man by doclifter -->
5 <refentry id='dbus-daemon'>
6 <!--   -->
7 <!--  dbus\-daemon manual page. -->
8 <!--  Copyright (C) 2003 Red Hat, Inc. -->
9
10 <refmeta>
11 <refentrytitle>dbus-daemon</refentrytitle>
12 <manvolnum>1</manvolnum>
13 </refmeta>
14 <refnamediv id='name'>
15 <refname>dbus-daemon</refname>
16 <refpurpose>Message bus daemon</refpurpose>
17 </refnamediv>
18 <!-- body begins here -->
19 <refsynopsisdiv id='synopsis'>
20 <cmdsynopsis>
21   <command>dbus-daemon</command></cmdsynopsis>
22 <cmdsynopsis>
23   <command>dbus-daemon</command>    <arg choice='opt'>--version </arg>
24     <arg choice='opt'>--session </arg>
25     <arg choice='opt'>--system </arg>
26     <arg choice='opt'>--config-file=<replaceable>FILE</replaceable></arg>
27     <arg choice='opt'><arg choice='plain'>--print-address </arg><arg choice='opt'><replaceable>=DESCRIPTOR</replaceable></arg></arg>
28     <arg choice='opt'><arg choice='plain'>--print-pid </arg><arg choice='opt'><replaceable>=DESCRIPTOR</replaceable></arg></arg>
29     <arg choice='opt'>--fork </arg>
30     <sbr/>
31 </cmdsynopsis>
32 </refsynopsisdiv>
33
34
35 <refsect1 id='description'><title>DESCRIPTION</title>
36 <para><command>dbus-daemon</command> is the D-Bus message bus daemon. See
37 <ulink url='http://www.freedesktop.org/software/dbus/'>http://www.freedesktop.org/software/dbus/</ulink> for more information about
38 the big picture. D-Bus is first a library that provides one-to-one
39 communication between any two applications; <command>dbus-daemon</command> is an
40 application that uses this library to implement a message bus
41 daemon. Multiple programs connect to the message bus daemon and can
42 exchange messages with one another.</para>
43
44
45 <para>There are two standard message bus instances: the systemwide message bus 
46 (installed on many systems as the "messagebus" init service) and the 
47 per-user-login-session message bus (started each time a user logs in).
48 <command>dbus-daemon</command> is used for both of these instances, but with 
49 a different configuration file.</para>
50
51
52 <para>The --session option is equivalent to
53 "--config-file=/etc/dbus-1/session.conf" and the --system
54 option is equivalent to
55 "--config-file=/etc/dbus-1/system.conf". By creating 
56 additional configuration files and using the --config-file option,
57 additional special-purpose message bus daemons could be created.</para>
58
59
60 <para>The systemwide daemon is normally launched by an init script, 
61 standardly called simply "messagebus".</para> 
62
63
64 <para>The systemwide daemon is largely used for broadcasting system events, 
65 such as changes to the printer queue, or adding/removing devices.</para>
66
67
68 <para>The per-session daemon is used for various interprocess communication 
69 among desktop applications (however, it is not tied to X or the GUI 
70 in any way).</para>
71
72
73 <para>SIGHUP will cause the D-Bus daemon to PARTIALLY reload its
74 configuration file and to flush its user/group information caches. Some
75 configuration changes would require kicking all apps off the bus; so they will
76 only take effect if you restart the daemon. Policy changes should take effect
77 with SIGHUP.</para>
78
79 </refsect1>
80
81 <refsect1 id='options'><title>OPTIONS</title>
82 <para>The following options are supported:</para>
83 <variablelist remap='TP'>
84   <varlistentry>
85   <term><option>--config-file=FILE</option></term>
86   <listitem>
87 <para>Use the given configuration file.</para>
88   </listitem>
89   </varlistentry>
90   <varlistentry>
91   <term><option>--fork</option></term>
92   <listitem>
93 <para>Force the message bus to fork and become a daemon, even if 
94 the configuration file does not specify that it should.
95 In most contexts the configuration file already gets this
96 right, though.</para>
97   </listitem>
98   </varlistentry>
99   <varlistentry>
100   <term><option>--print-address[=DESCRIPTOR]</option></term>
101   <listitem>
102 <para>Print the address of the message bus to standard output, or 
103 to the given file descriptor. This is used by programs that 
104 launch the message bus.</para>
105   </listitem>
106   </varlistentry>
107   <varlistentry>
108   <term><option>--print-pid[=DESCRIPTOR]</option></term>
109   <listitem>
110 <para>Print the process ID of the message bus to standard output, or 
111 to the given file descriptor. This is used by programs that 
112 launch the message bus.</para>
113   </listitem>
114   </varlistentry>
115   <varlistentry>
116   <term><option>--session</option></term>
117   <listitem>
118 <para>Use the standard configuration file for the per-login-session message
119 bus.</para>
120   </listitem>
121   </varlistentry>
122   <varlistentry>
123   <term><option>--system</option></term>
124   <listitem>
125 <para>Use the standard configuration file for the systemwide message bus.</para>
126   </listitem>
127   </varlistentry>
128   <varlistentry>
129   <term><option>--version</option></term>
130   <listitem>
131 <para>Print the version of the daemon.</para>
132
133   </listitem>
134   </varlistentry>
135 </variablelist>
136 </refsect1>
137
138 <refsect1 id='configuration_file'><title>CONFIGURATION FILE</title>
139 <para>A message bus daemon has a configuration file that specializes it
140 for a particular application. For example, one configuration 
141 file might set up the message bus to be a systemwide message bus, 
142 while another might set it up to be a per-user-login-session bus.</para>
143
144
145 <para>The configuration file also establishes resource limits, security
146 parameters, and so forth.</para>
147
148
149 <para>The configuration file is not part of any interoperability
150 specification and its backward compatibility is not guaranteed; this
151 document is documentation, not specification.</para>
152
153
154 <para>The standard systemwide and per-session message bus setups are
155 configured in the files "/etc/dbus-1/system.conf" and
156 "/etc/dbus-1/session.conf".  These files normally
157 &lt;include&gt; a system-local.conf or session-local.conf; you can put local
158 overrides in those files to avoid modifying the primary configuration
159 files.</para>
160
161
162 <para>The configuration file is an XML document. It must have the following
163 doctype declaration:</para>
164 <literallayout remap='.nf'>
165
166    &lt;!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-Bus Bus Configuration 1.0//EN"
167     "<ulink url='http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd'>http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd</ulink>"&gt;
168
169 </literallayout> <!-- .fi -->
170
171
172 <para>The following elements may be present in the configuration file.</para>
173
174 <variablelist remap='TP'>
175   <varlistentry>
176   <term><emphasis remap='I'>&lt;busconfig&gt;</emphasis></term>
177   <listitem>
178 <para></para> 
179   </listitem>
180   </varlistentry>
181 </variablelist>
182
183 <para>Root element.</para>
184
185 <variablelist remap='TP'>
186   <varlistentry>
187   <term><emphasis remap='I'>&lt;type&gt;</emphasis></term>
188   <listitem>
189
190 <para></para> <!-- FIXME: blank list item -->
191   </listitem>
192   </varlistentry>
193 </variablelist>
194
195 <para>The well-known type of the message bus. Currently known values are
196 "system" and "session"; if other values are set, they should be
197 either added to the D-Bus specification, or namespaced.  The last
198 &lt;type&gt; element "wins" (previous values are ignored).</para>
199
200
201 <para>Example: &lt;type&gt;session&lt;/type&gt;</para>
202
203 <variablelist remap='TP'>
204   <varlistentry>
205   <term><emphasis remap='I'>&lt;include&gt;</emphasis></term>
206   <listitem>
207 <para></para> 
208   </listitem>
209   </varlistentry>
210 </variablelist>
211
212 <para>Include a file &lt;include&gt;filename.conf&lt;/include&gt; at this point.  If the
213 filename is relative, it is located relative to the configuration file
214 doing the including.</para>
215
216
217 <para>&lt;include&gt; has an optional attribute "ignore_missing=(yes|no)"
218 which defaults to "no" if not provided. This attribute 
219 controls whether it's a fatal error for the included file 
220 to be absent.</para>
221
222 <variablelist remap='TP'>
223   <varlistentry>
224   <term><emphasis remap='I'>&lt;includedir&gt;</emphasis></term>
225   <listitem>
226
227 <para></para> <!-- FIXME: blank list item -->
228   </listitem>
229   </varlistentry>
230 </variablelist>
231
232 <para>Include all files in &lt;includedir&gt;foo.d&lt;/includedir&gt; at this
233 point. Files in the directory are included in undefined order.
234 Only files ending in ".conf" are included.</para>
235
236
237 <para>This is intended to allow extension of the system bus by particular
238 packages. For example, if CUPS wants to be able to send out
239 notification of printer queue changes, it could install a file to
240 /etc/dbus-1/system.d that allowed all apps to receive
241 this message and allowed the printer daemon user to send it.</para>
242
243 <variablelist remap='TP'>
244   <varlistentry>
245   <term><emphasis remap='I'>&lt;user&gt;</emphasis></term>
246   <listitem>
247
248 <para></para> <!-- FIXME: blank list item -->
249   </listitem>
250   </varlistentry>
251 </variablelist>
252
253 <para>The user account the daemon should run as, as either a username or a
254 UID. If the daemon cannot change to this UID on startup, it will exit.
255 If this element is not present, the daemon will not change or care
256 about its UID.</para>
257
258
259 <para>The last &lt;user&gt; entry in the file "wins", the others are ignored.</para>
260
261
262 <para>The user is changed after the bus has completed initialization.  So
263 sockets etc. will be created before changing user, but no data will be
264 read from clients before changing user. This means that sockets 
265 and PID files can be created in a location that requires root 
266 privileges for writing.</para>
267
268 <variablelist remap='TP'>
269   <varlistentry>
270   <term><emphasis remap='I'>&lt;fork&gt;</emphasis></term>
271   <listitem>
272 <para></para>    
273   </listitem>
274   </varlistentry>
275 </variablelist>
276
277 <para>If present, the bus daemon becomes a real daemon (forks 
278 into the background, etc.). This is generally used 
279 rather than the --fork command line option.</para>
280
281 <variablelist remap='TP'>
282   <varlistentry>
283   <term><emphasis remap='I'>&lt;listen&gt;</emphasis></term>
284   <listitem>
285
286 <para></para> <!-- FIXME: blank list item -->
287   </listitem>
288   </varlistentry>
289 </variablelist>
290
291 <para>Add an address that the bus should listen on. The 
292 address is in the standard D-Bus format that contains 
293 a transport name plus possible parameters/options.</para>
294
295
296 <para>Example: &lt;listen&gt;unix:path=/tmp/foo&lt;/listen&gt;</para>
297
298
299 <para>If there are multiple &lt;listen&gt; elements, then the bus listens 
300 on multiple addresses. The bus will pass its address to 
301 started services or other interested parties with 
302 the last address given in &lt;listen&gt; first. That is, 
303 apps will try to connect to the last &lt;listen&gt; address first.</para>
304
305 <variablelist remap='TP'>
306   <varlistentry>
307   <term><emphasis remap='I'>&lt;auth&gt;</emphasis></term>
308   <listitem>
309
310 <para></para> <!-- FIXME: blank list item -->
311   </listitem>
312   </varlistentry>
313 </variablelist>
314
315 <para>Lists permitted authorization mechanisms. If this element doesn't
316 exist, then all known mechanisms are allowed.  If there are multiple
317 &lt;auth&gt; elements, all the listed mechanisms are allowed.  The order in
318 which mechanisms are listed is not meaningful.</para>
319     
320
321 <para>Example: &lt;auth&gt;EXTERNAL&lt;/auth&gt;</para>
322
323
324 <para>Example: &lt;auth&gt;DBUS_COOKIE_SHA1&lt;/auth&gt;</para>
325
326 <variablelist remap='TP'>
327   <varlistentry>
328   <term><emphasis remap='I'>&lt;servicedir&gt;</emphasis></term>
329   <listitem>
330
331 <para></para> <!-- FIXME: blank list item -->
332   </listitem>
333   </varlistentry>
334 </variablelist>
335
336 <para>Adds a directory to scan for .service files. Directories are
337 scanned starting with the last to appear in the config file 
338 (the first .service file found that provides a particular 
339 service will be used).</para>
340
341
342 <para>Service files tell the bus how to automatically start a program.
343 They are primarily used with the per-user-session bus, 
344 not the systemwide bus.</para>
345
346 <variablelist remap='TP'>
347   <varlistentry>
348   <term><emphasis remap='I'>&lt;standard_session_servicedirs/&gt;</emphasis></term>
349   <listitem>
350
351 <para></para> <!-- FIXME: blank list item -->
352   </listitem>
353   </varlistentry>
354 </variablelist>
355
356 <para>&lt;standard_session_servicedirs/&gt; is equivalent to specifying a series
357 of &lt;servicedir/&gt; elements for each of the data directories in the "XDG
358 Base Directory Specification" with the subdirectory "dbus-1/services",
359 so for example "/usr/share/dbus-1/services" would be among the
360 directories searched.</para>
361
362
363 <para>The "XDG Base Directory Specification" can be found at
364 <ulink url='http://freedesktop.org/wiki/Standards/basedir-spec'>http://freedesktop.org/wiki/Standards/basedir-spec</ulink> if it hasn't moved,
365 otherwise try your favorite search engine.</para>
366
367
368 <para>The &lt;standard_session_servicedirs/&gt; option is only relevant to the
369 per-user-session bus daemon defined in
370 /etc/dbus-1/session.conf. Putting it in any other
371 configuration file would probably be nonsense.</para>
372
373 <variablelist remap='TP'>
374   <varlistentry>
375   <term><emphasis remap='I'>&lt;limit&gt;</emphasis></term>
376   <listitem>
377
378 <para></para> <!-- FIXME: blank list item -->
379   </listitem>
380   </varlistentry>
381 </variablelist>
382
383 <para>&lt;limit&gt; establishes a resource limit. For example:</para>
384 <literallayout remap='.nf'>
385   &lt;limit name="max_message_size"&gt;64&lt;/limit&gt;
386   &lt;limit name="max_completed_connections"&gt;512&lt;/limit&gt;
387 </literallayout> <!-- .fi -->
388
389
390 <para>The name attribute is mandatory.
391 Available limit names are:</para>
392 <literallayout remap='.nf'>
393       "max_incoming_bytes"         : total size in bytes of messages
394                                      incoming from a single connection
395       "max_outgoing_bytes"         : total size in bytes of messages
396                                      queued up for a single connection
397       "max_message_size"           : max size of a single message in
398                                      bytes
399       "service_start_timeout"      : milliseconds (thousandths) until 
400                                      a started service has to connect
401       "auth_timeout"               : milliseconds (thousandths) a
402                                      connection is given to
403                                      authenticate
404       "max_completed_connections"  : max number of authenticated connections  
405       "max_incomplete_connections" : max number of unauthenticated
406                                      connections
407       "max_connections_per_user"   : max number of completed connections from
408                                      the same user
409       "max_pending_service_starts" : max number of service launches in
410                                      progress at the same time
411       "max_names_per_connection"   : max number of names a single 
412                                      connection can own
413       "max_match_rules_per_connection": max number of match rules for a single 
414                                         connection
415       "max_replies_per_connection" : max number of pending method 
416                                      replies per connection
417                                      (number of calls-in-progress)
418       "reply_timeout"              : milliseconds (thousandths) 
419                                      until a method call times out   
420 </literallayout> <!-- .fi -->
421
422
423 <para>The max incoming/outgoing queue sizes allow a new message to be queued
424 if one byte remains below the max. So you can in fact exceed the max
425 by max_message_size.</para>
426
427
428 <para>max_completed_connections divided by max_connections_per_user is the
429 number of users that can work together to denial-of-service all other users by using
430 up all connections on the systemwide bus.</para>
431
432
433 <para>Limits are normally only of interest on the systemwide bus, not the user session 
434 buses.</para>
435
436 <variablelist remap='TP'>
437   <varlistentry>
438   <term><emphasis remap='I'>&lt;policy&gt;</emphasis></term>
439   <listitem>
440
441 <para></para> <!-- FIXME: blank list item -->
442   </listitem>
443   </varlistentry>
444 </variablelist>
445
446 <para>The &lt;policy&gt; element defines a security policy to be applied to a particular
447 set of connections to the bus. A policy is made up of
448 &lt;allow&gt; and &lt;deny&gt; elements. Policies are normally used with the systemwide bus;
449 they are analogous to a firewall in that they allow expected traffic 
450 and prevent unexpected traffic.</para>
451
452
453 <para>The &lt;policy&gt; element has one of three attributes:</para>
454 <literallayout remap='.nf'>
455   context="(default|mandatory)"
456   user="username or userid"
457   group="group name or gid"
458 </literallayout> <!-- .fi -->
459
460
461 <para> 
462 Policies are applied to a connection as follows:</para>
463 <literallayout remap='.nf'>
464    - all context="default" policies are applied
465    - all group="connection's user's group" policies are applied
466      in undefined order
467    - all user="connection's auth user" policies are applied
468      in undefined order
469    - all context="mandatory" policies are applied
470 </literallayout> <!-- .fi -->
471
472
473 <para>Policies applied later will override those applied earlier, 
474 when the policies overlap. Multiple policies with the same 
475 user/group/context are applied in the order they appear 
476 in the config file.</para>
477
478 <variablelist remap='TP'>
479   <varlistentry>
480   <term><emphasis remap='I'>&lt;deny&gt;</emphasis></term>
481   <listitem>
482 <para><emphasis remap='I'>&lt;allow&gt;</emphasis></para>
483
484   </listitem>
485   </varlistentry>
486 </variablelist>
487
488 <para>A &lt;deny&gt; element appears below a &lt;policy&gt; element and prohibits some
489 action. The &lt;allow&gt; element makes an exception to previous &lt;deny&gt;
490 statements, and works just like &lt;deny&gt; but with the inverse meaning.</para>
491
492
493 <para>The possible attributes of these elements are:</para>
494 <literallayout remap='.nf'>
495    send_interface="interface_name"
496    send_member="method_or_signal_name" 
497    send_error="error_name" 
498    send_destination="name" 
499    send_type="method_call" | "method_return" | "signal" | "error" 
500    send_path="/path/name"
501
502    receive_interface="interface_name"
503    receive_member="method_or_signal_name" 
504    receive_error="error_name" 
505    receive_sender="name" 
506    receive_type="method_call" | "method_return" | "signal" | "error"
507    receive_path="/path/name"
508
509    send_requested_reply="true" | "false"
510    receive_requested_reply="true" | "false"
511
512    eavesdrop="true" | "false"
513
514    own="name"
515    user="username"
516    group="groupname"
517 </literallayout> <!-- .fi -->
518
519
520 <para>Examples:</para>
521 <literallayout remap='.nf'>
522    &lt;deny send_interface="org.freedesktop.System" send_member="Reboot"/&gt; 
523    &lt;deny receive_interface="org.freedesktop.System" receive_member="Reboot"/&gt;
524    &lt;deny own="org.freedesktop.System"/&gt;
525    &lt;deny send_destination="org.freedesktop.System"/&gt;
526    &lt;deny receive_sender="org.freedesktop.System"/&gt;
527    &lt;deny user="john"/&gt;
528    &lt;deny group="enemies"/&gt;
529 </literallayout> <!-- .fi -->
530
531
532 <para>The &lt;deny&gt; element's attributes determine whether the deny "matches" a
533 particular action. If it matches, the action is denied (unless later
534 rules in the config file allow it).</para>
535
536
537 <para>send_destination and receive_sender rules mean that messages may not be
538 sent to or received from the *owner* of the given name, not that
539 they may not be sent *to that name*. That is, if a connection
540 owns services A, B, C, and sending to A is denied, sending to B or C
541 will not work either.</para>
542
543
544 <para>The other send_* and receive_* attributes are purely textual/by-value
545 matches against the given field in the message header.</para>
546
547
548 <para>"Eavesdropping" occurs when an application receives a message that
549 was explicitly addressed to a name the application does not own.
550 Eavesdropping thus only applies to messages that are addressed to
551 services (i.e. it does not apply to signals).</para>
552
553
554 <para>For &lt;allow&gt;, eavesdrop="true" indicates that the rule matches even 
555 when eavesdropping. eavesdrop="false" is the default and means that 
556 the rule only allows messages to go to their specified recipient.
557 For &lt;deny&gt;, eavesdrop="true" indicates that the rule matches 
558 only when eavesdropping. eavesdrop="false" is the default for &lt;deny&gt;
559 also, but here it means that the rule applies always, even when 
560 not eavesdropping. The eavesdrop attribute can only be combined with
561 receive rules (with receive_* attributes).</para>
562
563
564
565 <para>The [send|receive]_requested_reply attribute works similarly to the eavesdrop
566 attribute. It controls whether the &lt;deny&gt; or &lt;allow&gt; matches a reply
567 that is expected (corresponds to a previous method call message).
568 This attribute only makes sense for reply messages (errors and method
569 returns), and is ignored for other message types.</para>
570
571
572 <para>For &lt;allow&gt;, [send|receive]_requested_reply="true" is the default and indicates that
573 only requested replies are allowed by the
574 rule. [send|receive]_requested_reply="false" means that the rule allows any reply
575 even if unexpected.</para>
576
577
578 <para>For &lt;deny&gt;, [send|receive]_requested_reply="false" is the default but indicates that
579 the rule matches only when the reply was not
580 requested. [send|receive]_requested_reply="true" indicates that the rule applies
581 always, regardless of pending reply state.</para>
582
583
584 <para>user and group denials mean that the given user or group may 
585 not connect to the message bus.</para>
586
587
588 <para>For "name", "username", "groupname", etc.
589 the character "*" can be substituted, meaning "any." Complex globs
590 like "foo.bar.*" aren't allowed for now because they'd be work to
591 implement and maybe encourage sloppy security anyway.</para>
592
593
594 <para>It does not make sense to deny a user or group inside a &lt;policy&gt;
595 for a user or group; user/group denials can only be inside
596 context="default" or context="mandatory" policies.</para>
597
598
599 <para>A single &lt;deny&gt; rule may specify combinations of attributes such as
600 send_destination and send_interface and send_type. In this case, the
601 denial applies only if both attributes match the message being denied.
602 e.g. &lt;deny send_interface="foo.bar" send_destination="foo.blah"/&gt; would
603 deny messages with the given interface AND the given bus name.
604 To get an OR effect you specify multiple &lt;deny&gt; rules.</para>
605
606
607 <para>You can't include both send_ and receive_ attributes on the same
608 rule, since "whether the message can be sent" and "whether it can be
609 received" are evaluated separately.</para>
610
611
612 <para>Be careful with send_interface/receive_interface, because the 
613 interface field in messages is optional.</para>
614
615 <variablelist remap='TP'>
616   <varlistentry>
617   <term><emphasis remap='I'>&lt;selinux&gt;</emphasis></term>
618   <listitem>
619
620 <para></para> <!-- FIXME: blank list item -->
621   </listitem>
622   </varlistentry>
623 </variablelist>
624
625 <para>The &lt;selinux&gt; element contains settings related to Security Enhanced Linux.
626 More details below.</para>
627
628 <variablelist remap='TP'>
629   <varlistentry>
630   <term><emphasis remap='I'>&lt;associate&gt;</emphasis></term>
631   <listitem>
632
633 <para></para> <!-- FIXME: blank list item -->
634   </listitem>
635   </varlistentry>
636 </variablelist>
637
638 <para>An &lt;associate&gt; element appears below an &lt;selinux&gt; element and
639 creates a mapping. Right now only one kind of association is possible:</para>
640 <literallayout remap='.nf'>
641    &lt;associate own="org.freedesktop.Foobar" context="foo_t"/&gt; 
642 </literallayout> <!-- .fi -->
643
644
645 <para>This means that if a connection asks to own the name
646 "org.freedesktop.Foobar" then the source context will be the context
647 of the connection and the target context will be "foo_t" - see the 
648 short discussion of SELinux below.</para>
649
650
651 <para>Note, the context here is the target context when requesting a name,
652 NOT the context of the connection owning the name.</para>
653
654
655 <para>There's currently no way to set a default for owning any name, if
656 we add this syntax it will look like:</para>
657 <literallayout remap='.nf'>
658    &lt;associate own="*" context="foo_t"/&gt; 
659 </literallayout> <!-- .fi -->
660 <para>If you find a reason this is useful, let the developers know.
661 Right now the default will be the security context of the bus itself.</para>
662
663
664 <para>If two &lt;associate&gt; elements specify the same name, the element
665 appearing later in the configuration file will be used.</para>
666
667 </refsect1>
668
669 <refsect1 id='selinux'><title>SELinux</title>
670 <para>See <ulink url='http://www.nsa.gov/selinux/'>http://www.nsa.gov/selinux/</ulink> for full details on SELinux. Some useful excerpts:</para>
671
672
673 <para>Every subject (process) and object (e.g. file, socket, IPC object,
674 etc) in the system is assigned a collection of security attributes,
675 known as a security context. A security context contains all of the
676 security attributes associated with a particular subject or object
677 that are relevant to the security policy.</para>
678
679
680 <para>In order to better encapsulate security contexts and to provide
681 greater efficiency, the policy enforcement code of SELinux typically
682 handles security identifiers (SIDs) rather than security contexts. A
683 SID is an integer that is mapped by the security server to a security
684 context at runtime.</para>
685
686
687 <para>When a security decision is required, the policy enforcement code
688 passes a pair of SIDs (typically the SID of a subject and the SID of
689 an object, but sometimes a pair of subject SIDs or a pair of object
690 SIDs), and an object security class to the security server. The object
691 security class indicates the kind of object, e.g. a process, a regular
692 file, a directory, a TCP socket, etc.</para>
693
694
695 <para>Access decisions specify whether or not a permission is granted for a
696 given pair of SIDs and class. Each object class has a set of
697 associated permissions defined to control operations on objects with
698 that class.</para>
699
700
701 <para>D-Bus performs SELinux security checks in two places.</para>
702
703
704 <para>First, any time a message is routed from one connection to another
705 connection, the bus daemon will check permissions with the security context of
706 the first connection as source, security context of the second connection
707 as target, object class "dbus" and requested permission "send_msg".</para>
708
709
710 <para>If a security context is not available for a connection 
711 (impossible when using UNIX domain sockets), then the target 
712 context used is the context of the bus daemon itself.
713 There is currently no way to change this default, because we're 
714 assuming that only UNIX domain sockets will be used to 
715 connect to the systemwide bus. If this changes, we'll 
716 probably add a way to set the default connection context.</para>
717
718
719 <para>Second, any time a connection asks to own a name, 
720 the bus daemon will check permissions with the security 
721 context of the connection as source, the security context specified
722 for the name in the config file as target, object 
723 class "dbus" and requested permission "acquire_svc".</para>
724
725
726 <para>The security context for a bus name is specified with the 
727 &lt;associate&gt; element described earlier in this document.
728 If a name has no security context associated in the 
729 configuration file, the security context of the bus daemon 
730 itself will be used.</para>
731
732 </refsect1>
733
734 <refsect1 id='author'><title>AUTHOR</title>
735 <para>See <ulink url='http://www.freedesktop.org/software/dbus/doc/AUTHORS'>http://www.freedesktop.org/software/dbus/doc/AUTHORS</ulink></para>
736
737 </refsect1>
738
739 <refsect1 id='bugs'><title>BUGS</title>
740 <para>Please send bug reports to the D-Bus mailing list or bug tracker,
741 see <ulink url='http://www.freedesktop.org/software/dbus/'>http://www.freedesktop.org/software/dbus/</ulink></para>
742 </refsect1>
743 </refentry>
744