parse XML configuration files #159
Conversation
jokeyrhyme
changed the title
jokeyrhyme
force-pushed
the
78-parse-xml-configuration-files
branch
from
bcea200 to
07e1119
Compare
jokeyrhyme
force-pushed
the
78-parse-xml-configuration-files
branch
2 times, most recently
from
9320376 to
6402177
Compare
Sure thing.
Awesome! I'll have a look soon.
That's ok, we can handle them later. If you could list them here, that would be great though, just to ensure that we don't end up leaving something very important/critical. Also do we add tests to parse system and session configuration from |
Do you mean I should copy the default configuration files from dbus-broker in as tests? Or should busd try to read these files by default if run with |
So busd should most definitely read them from those paths and later when we've some build configuration (#77), we can make the paths configurable at build time too. I was saying we should have tests that also try to load from those paths on Linux but we can also copy them into the repo to keep the tests self-contained (then the tests don't need to be linux-only). |
|
I've updated the TODO checklist in the PR description |
jokeyrhyme
force-pushed
the
78-parse-xml-configuration-files
branch
2 times, most recently
from
57ae57a to
102cf3a
Compare
jokeyrhyme
force-pushed
the
78-parse-xml-configuration-files
branch
from
eb3abf1 to
78aa1f2
Compare
There was a problem hiding this comment.
Getting real close now. Could you please:
- do a self-review, going line by line to ensure everything is in order. I see things like use of
eprintlnetc. - See that the commit logs are in order. E.g I see a commit not even bothering with
.at the end of sentences and one of them using past tense to describe the changes in the commit. BTW, you can writeFixes #1, #2, .... - Squash the last fixup commit into the appropriate commit(s).
I'm guessing you have tested both --system as well?
This crate offers a serde-compatible Deserializer for XML data.
We can deserialize an XML file using the "serde" and "quick-xml" crates. Creating a struct type with nested structs within is a direct approach that works well with `#[derive(Deserialize)]`. However, the result isn't optimal for consumption, and also makes it very difficult to implement aspects of the business logic that are sensitive to the order of certain XML elements, e.g. `<bus>`, `<include>`, etc. So our approach is to first deserialize into a `Vec<Element>` (inspired by @elmarco 's work over in dbus2#23 ). Importantly, by starting with this intermediate representation, we can preserve the XML author's intention regarding the order of elements. Then we replace any `<include>` and `<includedir>` elements with the parsed contents the XML files to which they refer, further replacing any `<include>` and `<includedir>` elements within those. Finally, we can make one final iteration over the `Vec<Element>` to produce the final optimally-structured `Config`. Fixes dbus2#78
jokeyrhyme
force-pushed
the
78-parse-xml-configuration-files
branch
from
78aa1f2 to
2b9ab6e
Compare
Yep, I've run it in a container to confirm that it listens on the expected system socket However, I've not yet tried using this as a replacement for the actual system bus on my machine |
jokeyrhyme
force-pushed
the
78-parse-xml-configuration-files
branch
from
2b9ab6e to
1f9d177
Compare
jokeyrhyme
force-pushed
the
78-parse-xml-configuration-files
branch
from
1f9d177 to
2dbc4fd
Compare
jokeyrhyme
force-pushed
the
78-parse-xml-configuration-files
branch
from
2dbc4fd to
2c8b75c
Compare
We'll borrow this from dbus2#159 so that we can be clearer about the default address.
based on reading https://dbus.freedesktop.org/doc/dbus-daemon.1.html#configuration_file
Fixes #78 and #79 and #148
Related to #23 and #146
<limit>parts per Hardcoded security limits #148<policy>parts that we don't implement per Implement essential policy #79<policy>parts that evendbus-brokerdoesn't implement: feat: initial work on supporting dbus-daemon XML configuration files #146 (comment)<type><user><fork><keep_umask><syslog><pidfile><allow_anonymous><listen><auth><servicedir><include><includedir><standard_session_servicedirs /><standard_session_servicedirs /><standard_system_servicedirs /><standard_system_servicedirs /><policy><allow>and all supported attributes<deny>and all supported attributes<(allow|deny) send_member=...: Implement essential policy #79 (comment)TODOs for follow-up PRs:
<selinux><associate><apparmor><include>/<includedirs><include if_selinux_enabled=...><include selinux_root_relative=...><listen>better thanStringvalues (e.g. parse and validate into more useful type)<auth>better thanString, is there anenumof specific values we support< standard_session_servicedirs />in a system config<standard_system_servicedirs />in a session config<busconfig>Ord/PartialOrdtrait forPolicyto facilitate use during evaluation