Reload config on SELinux policy load

[matt-sheets]

When a new SELinux policy is loaded, the dbus config file it carries may have been updated as well. As such, we should reload the dbus configuration to catch any changes. This logic already exists in the dbus-daemon code and this change is largely based off of that code.

[dvdhrm]

Thanks for the PR! Sadly, we cannot rely on the broker to have its controller as parent PID. So this either needs channeling via the controller interface, or we simply make the launcher listen for these events and trigger the reload from there (which I think is preferable).

[dvdhrm]

The launcher/controller is not necessarily the parent PID. We need to pass this through the controller interface, just like the other activation related messages.

[matt-sheets]

Thanks for the feedback, I am not very familiar with the broker code, so any input is more than welcome.

I have tried to move the callback registration into launcher itself, but the actual callback method never seems to run. I am still digging into this but not making great progress.

Could you possibly point me in the correct direction when you say "channeling via the controller interface" if setting up the callback in the launcher doesn't work out?

[matt-sheets]

I have dug more and have come up with the following:

The reason why the launcher was not seeing the callback run and the broker was, is that the broker will call selinux_check_access which intern calls selinux_status_updated, which triggers the callback. The launcher has no such logic. As such I have come up with a few options for folks who know more than me to consider:

1. Add a polling method to the launcher to periodically call selinux_status_updated. This is probably the worst option but the most straightforward in terms of complexity.
2. Add an inotify on the selinux status file to call selinux_status_updated on a change. This will require additional SELinux policy to work in enforcing, specifically allowing the broker process to watch the file. Also, I noticed there was already some dir watching going on in dirwatch.c. We may be able to plug into that, but I got a bit lost in which actual process was watching what.
3. We signal the launcher to reload via a dbus message from the broker. I think I can do this from the broker code by calling controller_send_dbus_reload directly. But we get into a weird situation with registering the callback and having access to what that function needs in the call back. I have some ideas that should work but none of them are pretty.

[matt-sheets]

@dvdhrm Hi just a gentle ping about the proposed paths I laid out in my last comment.