Commit b0525241 authored by Havoc Pennington's avatar Havoc Pennington

2003-03-18 Havoc Pennington <hp@redhat.com>

	* doc/TODO: some notes on high-level todo items. Little nitpick
	stuff is all in @todo, so no need to add it here.

	* doc/config-file.txt: some notes on how config file might look
parent d04cc0dc
2003-03-18 Havoc Pennington <hp@redhat.com>
* doc/TODO: some notes on high-level todo items. Little nitpick
stuff is all in @todo, so no need to add it here.
* doc/config-file.txt: some notes on how config file might look
2003-03-18 Anders Carlsson <andersca@codefactory.se>
* configure.in: 0.6
......
- Service and message names should be more carefully restricted;
they should have a max length, may not be an empty string,
and perhaps should not be allowed to be a glob such as "*" since
the config file could conveniently use such notation.
Suggest requiring length > 0, length < max,
name contains at least one ".", no initial ".", and valid UTF-8.
That would prohibit plain "*" but not "foo.bar.baz.operator*"
For maximum convenience from all programming languages, we could go
further and just categorically ban nearly all non-alphanumeric
characters.
- Message matching rules (so broadcasts can be filtered) need sorting
out.
- How we will handle DCOP needs sorting out. Among other things, we
need to check that service and service-ownership semantics map to DCOP
reasonably well.
- Activation needs some careful additional thinking-through.
- Recursive/composite/etc. types and associated API, see mailing list.
- dbus-bus.h should contain convenience API for connecting to system
and login-session message buses (automatically handling env
variables etc.)
- Configuration file (working on that now)
- Property list feature on message bus (list of properties associated
with a connection). May also include message matching rules
that involve the properties of the source or destination
connection.
- Implement all the needed resource limits to keep clients from
killing the message bus.
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.
<include>
ignore_missing="(yes|no)" optional attribute, defaults to no
Include a file <include>filename.conf</include> at this point.
<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.
<listen>
address="name" mandatory attribute
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 address="unix:path=/tmp/foo"/>
If there are multiple <listen> elements, then the bus listens
on multiple addresses.
<auth>
Lists permitted authorization mechanisms. If this element doesn't
exist, then all known mechanisms are allowed. If there are
multiple <auth> elements, the last one wins (they are not merged).
<policy>
context="(default|required)" 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
- all user="connection's auth user" policies are applied
- all context="required" 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_connections">512</limit>
<deny>
send="messagename"
receive="messagename"
own="servicename"
send_to="servicename"
receive_from="servicename"
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"/>
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.
For "servicename" or "messagename" 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.
FIXME should we allow send/send_to and receive/receive_from
to both be specified, in which case they would be ANDed together?
e.g. <deny send="foo.bar" send_to="foo.blah"/> would deny
messages of the given name AND to the given service.
Probably need to see how hard/slow all this will be to implement.
<allow>
send="messagename"
receive="messagename"
own="servicename"
send_to="servicename"
receive_from="servicename"
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.
\ No newline at end of file
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment