First pass on OLPC security modifications to DBus
Havoc Pennington
hp at redhat.com
Fri Aug 17 14:40:12 PDT 2007
Hi,
Thanks for the patch, here are some comments:
- if we get one more of these besides selinux and olpc we will probably need
some kind of extensible security module thing ;-)
- isn't there some name for this feature other than "olpc"? something
specific to the security architecture or whatever?
- the config file setting should be like <fork/> where its presence
means "true"
(if we allowed "false" to override later in the file, that would be
done with a
<nofork/> or <noolpc/> but I think there's no need for that)
The point here is <olpc/> rather than <olpc>on</olpc>
- config file element needs a patch to the dbus-daemon.1.in man page
- the header is wrong on olpc.c, both the Emacs magic and the license don't
match the rest of dbus (olpc.h also)
- since you didn't have indent-tabs-mode nil, be sure to M-x untabify
to be sure none leaked in
- caching the system connection from dbus_bus_get() in a static variable
just raises questions and issues, I would not do it, just call dbus_bus_get
every time (and remember to unref the result). This will also theoretically
allow you to survive a system bus restart, for those who feel that is
feasible.
- bus_olpc_check_can_own() fails to set the DBusError in a few places...
it looks like this is intentional based on how this function is called, but
I'm not sure I understand the semantics? if there's no memory you
should BUS_SET_OOM presumably?
- your system bus service seems to use the path "/" which I would
consider bad practice,
it essentially encodes in the API that the process offers only that
single object and
API, while it would be reasonable to offer some other second API from the
process as well - say a system service control API with methods like Start()
and Stop(), just to speculate on a possible one. This is like
naming a global variable
"the variable" instead of "security_manager" or something.
- since bus_olpc_check_can_own connects to the system bus and blocks on it,
you probably want to take make it an error if the config file has bus type
"system" and also contains the <olpc/> element, or something...
- stdint.h should not be in olpc.h, since olpc.c is all
linux-specific anyway it's
fine in there, though using the dbus typedefs would be more consistent
- I would add the new config file element to one of the test config
files so the parsing code
at least gets tested
- I'm not sure how to meaningfully unit test the rest of this, but it
seems straightforward
so hopefully no big issues
We should carefully review for memory leaks and OOM handling and so
forth when you have a more final version of the patch, I did not step
through the code line-by-line yet.
Havoc
More information about the dbus
mailing list