new, simpler config language for Unix system services
<policy> language is complicated and difficult to get right, and policy fragments intended to apply to one system service can easily have "action at a distance" on an unrelated system service.
We should have a simpler policy language subset, either in the XML or out-of-band, in which things we do not want to encourage are simply not something you can express, and things we want to encourage are straightforward.
This is significantly complicated by the fact that the XML policy language is designed to be exhaustive: if you have a message or a connection in mind, you can start at the beginning, read the configuration files for the system or session bus to the end, and know without ambiguity whether the message/connection is allowed or denied. The policy language has no concept of "if no rules apply, do the reasonable thing". As a result, if someone designs a simpler policy language subset, it would probably need to be hooked into the XML policy language with something ugly and seemingly tautological like:
<policy context="default"> <allow reasonable_things="true"/> </policy>
in an appropriate location where it will take precedence over the system bus's default-deny policy (but to avoid introducing security regressions on upgrade, other
<policy> from a sysadmin must take precedence over it).
This is complicated further by the fact that restarting the dbus-daemon during runtime is not supported, reloading the dbus-daemon during upgrades is necessary, reloading the dbus-daemon requires policy and configuration files to be parsed, and the older dbus-daemon from which we are upgrading will refuse to parse configuration that contains any new syntax. This can be partially worked around with an
<include>, because failure to parse an included file is not fatal (I think?).
One example of a sketch of a new configuration language is in https://bugs.freedesktop.org/show_bug.cgi?id=50264#c1. Another is in https://bugs.freedesktop.org/show_bug.cgi?id=19593#c0. Another possibility would be that the D-Bus
.service file contains an outline of the service's high-level policy.