Active checks with dbus

[jw3]

Eliminate the calls to systemctl for service status checks, using dbus instead. This removes one potential pinch point where deployed rules can limit the call to systemctl. A side-effect of this is that the monitoring function now works even in the case of fully locked down system (ie. only the deny+any+all+all rule).

This also aligns both stages of deployment, deployment and rollback. Those stages used to be handled differently, where initial deployment only was a pipe write to refresh trust, while rollback deployment was a full daemon reload. Then the pipe write went away to align rule and trust writing, but there were some straggling issues that were left behind. These changes align the backends for both modes and resolve issues where fixes were present in one mode but not the other.

Closes #565

[jw3]

@tparchambault see how these changes play with your testing

[jw3]

@tparchambault eh hold off, there is another item to address

[tparchambault]

Since you committed some of your work 12 hrs ago and I put some observations into that other PR around that same time, did you see the following wrt timing, and did you intend for this change to also address it. I believe it will.

#560 (comment)

[jw3]

Yep, this PR will address the timing issues too.

[jw3]

@tparchambault OK, I just tested the latest on rhel, fapolicy-analyzer-0.0.0-1.255.ge34e2ed.el8.x86_64.rpm

See what you see with it.

[tparchambault]

Clean FC34 with only emacs, fapolicyd, and the generated fapolicy-analyzer rpm associated with this PR. Things look good. Ordering of fapolicyd shutdown/start reported in the journal is correct, deployed changes to the ancillary dbase were good, deployment timeout rollback also good.

[tparchambault]

I'm assuming the pyo3 daemon.rs deploy() throws exceptions lower down the stack on errors, i.e. from the calls it invokes and their children? I only saw this PyRuntimeError::new_err("Daemon unresponsive") in fn wait_for_daemon(target_state: State)

I'll dig around but for the sake of merging, if the answer is yes, we are good to go.

[jw3]

@tparchambault

Daemon unresponsive

This was an indeed an issue. When fapolicyd was in a Failed state (eg timed out on the max secs), wait_for_daemon didnt consider Failed equivalent to Inactive. This is now fixed.

Take another look and see if it all still functions as expected.

[jw3]

I am going to leave the stderr prints in there for the near term.

[tparchambault]

Functionally, on a clean FC34 rpm install, no issues observed.