diff options
| -rw-r--r-- | ChangeLog | 7 | ||||
| -rw-r--r-- | doc/TODO | 41 | ||||
| -rw-r--r-- | doc/config-file.txt | 154 |
3 files changed, 202 insertions, 0 deletions
@@ -1,3 +1,10 @@ +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 diff --git a/doc/TODO b/doc/TODO new file mode 100644 index 00000000..dffb7389 --- /dev/null +++ b/doc/TODO @@ -0,0 +1,41 @@ + + - 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. + + + diff --git a/doc/config-file.txt b/doc/config-file.txt new file mode 100644 index 00000000..c78a65b7 --- /dev/null +++ b/doc/config-file.txt @@ -0,0 +1,154 @@ + +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 |