Daemon state should not change when loading a user session json file

[tparchambault]

On RHEL86, V1.0.0, installed from EPEL-testing, with the fapolicyd stopped, after successfully loading (but not deploying) a saved session file, fapolicyd was started without any explicit user action, i.e. automagically started the daemon.

Use of our tool should not introduce side-effects.

[tparchambault]

There's an error in a log statement at line 144 in session.py which caused a python stack trace and I thought the thrown exception might have caused some fapolicd control logic to be bypassed. Fixing it did not address, or change the symptom of this issue.

Line 144 should be changed to:

logging.debug(f"Loaded dict = {data}")

The debug log messages generated when duplicating this issue (after fixing line 144)
:

DEBUG:root:Callback entered: MainWindow::on_openMenu_activate()
INFO:root:Entered SessionManager::open_edit_session(/root/test_session.json)
DEBUG:root:Loaded dict = [{'/root/anaconda-ks.cfg': 'Add'}]
DEBUG:root:SessionManager::open_edit_session():[<fapolicy_analyzer.ui.changeset_wrapper.TrustChangeset object at 0x7fbf29953e80>]
DEBUG:root:dispatch( RESTORE_SYSTEM_CHECKPOINT )
DEBUG:fapolicy_daemon.svc:waiting on fapolicyd to be Inactive...
DEBUG:fapolicy_daemon.svc:fapolicyd is now Inactive
DEBUG:fapolicy_pyo3.system:deploy_only
DEBUG:fapolicy_daemon.svc:waiting on fapolicyd to be Active...
DEBUG:root:_status(ServiceStatus.TRUE updated
DEBUG:root:monitor_daemon:Dispatch update request
DEBUG:root:on_update_daemon_status(ServiceStatus.TRUE)
DEBUG:fapolicy_daemon.svc:fapolicyd is now Active
DEBUG:root:dispatch( CLEAR_CHANGESET )
DEBUG:root:dispatch( APPLY_CHANGESETS )
DEBUG:fapolicy_pyo3.system:apply_changeset
INFO:root:SessionManager::autosave_edit_session()
DEBUG:root: Session autosave is disabled/bypassed
DEBUG:root:dispatch( REQUEST_ANCILLARY_TRUST )
DEBUG:fapolicy_pyo3.check:BatchConf: recs: 2, tc:1, tl:1, bc:1, bl:2
DEBUG:root:_update_fapd_status(ServiceStatus.TRUE)

[tparchambault]

Will verify that this is still an issue.

[tparchambault]

Verified on the FC38 platform that loading a session json file will start the fapd daemon if stopped initially.

[tparchambault]

Captured stacktrace from redux land (using traceback.print_stack()) as I'm currently reverse engineering things to determine iF the dispatch(RESTORE_SYSTEM_CHECKPOINT) really needs to invoke rollback_fapolicyd() [system_feature.py:274] after restoring the system object, and of course, what other user workflows ultimately call this same code and absolutely do need rollback_fapolicyd() to return fapd to a known state. TBD.

I expect that I'll have to provide some new functionality to only rollback the system object, i.e. add a new function _restore_system_checkpoint() with associated redux events/callbacks.

[jw3]

determine iF the dispatch(RESTORE_SYSTEM_CHECKPOINT) really needs to invoke rollback_fapolicyd()

It does when it is used in __display_deploy_revert_dialog

For the session restore it does not.

The quickest fix appears to be adding a boolean flag to the action to allow the callsite to specify whether to rollback or not.