Customizable initial application view loading from the config file

[dorschs57]

Right now this is manual process. To set your initial view update your config.toml file with a section like

[ui]
initial_view = 'trust'

The possible values are "trust", "rules", "audit log", "syslog", or "profiler". With the default being "rules".

As part of this change the I removed the disabling of the trust menu option when you are on the trust screen. If the user is on the trust page and they hit the trust menu option again it just refreshes the page.

Closes #773 Closes #804

[dorschs57]

@tparchambault Can you give the session saving and reloading a spin on this branch. I created a reusable widget to generate a file chooser dialog and switched all the places we were repeating ourselves in the code over to use it. The session management stuff used it in 3 different places.

[jw3]

@dorschs57 this picked up a conflict from master

[dorschs57]

@jw3 I put that minor change in to remove the + buttons.

[jw3]

@tparchambault any comment on this one? I tested the pickers for the session operations, seemed to be in order.

[tparchambault]

Currently reviewing it...

Can the generated toml file contain a comment with the possible valid choices for the option? Not this PR but downstream...

The possible values are "trust", "rules", "audit log", "syslog", or "profiler".

[jw3]

Can the generated toml file contain a comment with the possible valid choices for the option? Not this PR but downstream...

It could. Though the comment in an existing config would be inaccurate if we add a new view.

User guide is probably the place for it. There is a section there now describing it.

[tparchambault]

Are we adding an additional *.toml file or renaming the existing fapolicy-analyzer.toml to config.toml? I'm hoping the latter. I'm testing currently within the dev env; Maybe when I do the install over Rhel86, I'll answer my own question.

[jw3]

It is renamed

[tparchambault]

Independent of our tool but something we need to be aware of, as something @jw3 also wrestled with yesterday:

[toma@son-o-wimpy ~]$ journalctl -f -- Logs begin at Fri 2023-03-10 14:00:48 EST. -- Mar 10 14:48:54 son-o-wimpy fapolicyd[4399]: Database checks OK Mar 10 14:48:55 son-o-wimpy fapolicyd[4399]: Starting to listen for events Mar 10 14:48:56 son-o-wimpy dbus-daemon[898]: [system] Successfully activated service 'org.fedoraproject.Setroubleshootd' Mar 10 14:48:57 son-o-wimpy setroubleshoot[4401]: AnalyzeThread.run(): Cancel pending alarm Mar 10 14:48:58 son-o-wimpy dbus-daemon[898]: [system] Activating service name='org.fedoraproject.SetroubleshootPrivileged' requested by ':1.985' (uid=980 pid=4401 comm="/usr/libexec/platform-python -Es /usr/sbin/setroub" label="system_u:system_r:setroubleshootd_t:s0-s0:c0.c1023") (using servicehelper) Mar 10 14:48:58 son-o-wimpy dbus-daemon[898]: [system] Successfully activated service 'org.fedoraproject.SetroubleshootPrivileged' Mar 10 14:48:58 son-o-wimpy dbus-daemon[898]: [system] Successfully activated service 'org.fedoraproject.SetroubleshootPrivileged' Mar 10 14:49:00 son-o-wimpy setroubleshoot[4401]: SELinux is preventing fapolicyd from write access on the file fapolicyd.pid. For complete SELinux messages run: sealert -l c719e1c0-b6e1-462a-b40f-ccbb8ba66612 Mar 10 14:49:00 son-o-wimpy setroubleshoot[4401]: SELinux is preventing fapolicyd from write access on the file fapolicyd.pid.

Over RHEL8.6 via an RPM install, I was testing control of fapolicyd from fapolicy-analyzer. Subsequent attempts to control fapolicyd were successful. Go figure...

I have observed other permission errors on occasion and am curious if the pkexec session authentication is time-constrained, i.e. no traffic eventually times out? I'm going to let the fapa sit for 15m while I enjoy some unhealthy carbs... not reproducible but adding journald msgs associated with this event for posterity.

[tparchambault]

Only one anomaly observed and I'm assuming it's independent of this PR: After Deploying Changesets and allowing the Accept these changes? count-down dialog to expire, which initiated an automatic Trust rollback, the previous pre-deployment session state was not reloaded or at least visible in the Ancillary Trust view, (which by itself is neither good nor bad, just a design choice), however the application state remained in the pending changes state such that attempts to quit were met with the You have unapplied changes dialog. This may be a known issue.

[jw3]

I think the current behavior is sane as implicitly discarding the current working copy just because the deployment was cancelled would not be correct either.

I believe #603 rounds it all out by allowing explicit discard of the current working copy.