summaryrefslogtreecommitdiffstats
path: root/doc/config-file.txt
blob: ed3cdfab000805357a8794561a8892ed6db0f868 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233

D-BUS message bus daemon configuration
===

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

A DTD should be written here eventually, but for now I suck.

Doctype declaration:

   <!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN"
    "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">

Elements:

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

    Example: <type>session</type>

 <include>
  ignore_missing="(yes|no)"   optional attribute, defaults to no
   
    Include a file <include>filename.conf</include> at this point.

 <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/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 doesn't have and 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.

 <fork>
    
    If present, the bus daemon becomes a real daemon (forks 
    into the background, etc.)

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

 <policy>
  context="(default|mandatory)"  one of the context/user/group
                                 attributes is mandatory
  user="username or userid"
  group="group name or gid"

    Encloses a policy to be applied to a particular set of 
    connections to the bus. A policy is made up of <limit>, 
    <allow>, <deny> elements.
  
    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.

 <limit>
  name="resource name"  mandatory
  
    Appears below a <policy> element and establishes a resource
    limit. For example:
      <limit name="max_message_size">64</limit>
      <limit name="max_completed_connections">512</limit>

    Available limits are:
      "max_incoming_bytes"         : total size in bytes of messages
                                     incoming from a connection
      "max_outgoing_bytes"         : total size in bytes of messages
                                     queued up for a connection
      "max_message_size"           : max size of a single message in
                                     bytes
      "activation_timeout"         : milliseconds (thousandths) until 
                                     an activated 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

    Some notes:

       - 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 / max_connections_per_user is 
         the number of users that can work together to DOS all 
         other users by using up all connections

 <deny>
  send="messagename"
  receive="messagename"
  own="servicename"
  send_to="servicename"
  receive_from="servicename"
  user="username"
  group="groupname"

    Examples:
       <deny send="org.freedesktop.System.Reboot"/> 
       <deny receive="org.freedesktop.System.Reboot"/>
       <deny own="org.freedesktop.System"/>
       <deny send_to="org.freedesktop.System"/>
       <deny receive_from="org.freedesktop.System"/>
       <deny user="john"/>
       <deny group="enemies"/>

    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.

    user and group denials mean that the given user or group may 
    not connect to the message bus.

    For "servicename" or "messagename" or "username" or "groupname"
    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.

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

 <allow>
  send="messagename"
  receive="messagename"
  own="servicename"
  send_to="servicename"
  receive_from="servicename"
  user="username"
  group="groupname"

    Makes an exception to previous <deny> statements. Works 
    just like <deny> but with the inverse meaning.

    An <allow> only punches holes in the equivalent <deny>, it does
    not unconditionally allow the message. For example:

      <deny send="*"/>
      <deny send_to="*"/>
      <allow send="org.foo.Bar"/>

    Here the policy still doesn't allow sending any messages, because 
    no recipients have been allowed. You have to add 
    <allow send_to="something"/> to make the policy useful.