Move D-Bus support from bridge into usbguard-daemon. #319
Conversation
|
I can take care of the rebase. |
Allen-Webb
force-pushed
the
dbus
branch
4 times, most recently
from
4fc3385
to
f4e62e4
Compare
Allen-Webb
force-pushed
the
dbus
branch
2 times, most recently
from
65e97a5
to
ea0ab0b
Compare
|
I ended up having to move all the glib initialization out of the constructor into the D-Bus IPC server thread. |
|
The change as is doesn't currently provide a way to offer the D-Bus interface on the session bus, it is system only. I don't believe that will be a problem, but I thought I would highlight it in case you all are aware of particular reasons to also support binding to session buses. |
| @@ -339,6 +527,30 @@ namespace usbguard | |||
| with_interface_string.c_str()); | |||
| return builder; | |||
| } | |||
|
|
|||
| void DBusIPCServerPrivate::addAllowedUID(uid_t uid, const IPCServer::AccessControl& ac) | |||
There was a problem hiding this comment.
What is the current behavior without these functions implemented? If it is expected for them to be empty, could you add a comment to make that clear? Thanks
There was a problem hiding this comment.
I added a comment.
| } | ||
|
|
||
| void IPCServer::addAllowedUID(uid_t uid, const IPCServer::AccessControl& ac) | ||
| { | ||
| d_pointer->addAllowedUID(uid, ac); | ||
| for (const auto& d_pointer : d_pointers) { | ||
| d_pointer->addAllowedUID(uid, ac); |
There was a problem hiding this comment.
What's the intended behavior if any of the IPC implementation fail? Should we check the return values?
There was a problem hiding this comment.
There aren't return values to check. Though I did go through and convert some error log statements to exceptions, so the D-Bus IPC server better matches the behavior of the libqb IPC server code.
Allen-Webb
force-pushed
the
dbus
branch
2 times, most recently
from
aa97914
to
bd4a9d3
Compare
No description provided.