Version 1.2.0-rcN release testing/observations/notes.

[tparchambault]

Starting the V1.2.0-rc1 testing with the rpms available under GitHub releases page.

[tparchambault]

Testing over FC38:

1. Performed an installation w/o the prior installation of fapolicyd. Immediately upon invoking the fapa, the expected dialog was raised. I would (subjectively) like to see fapolicyd as an rpm dependency of the fapolicy-analyzer rpm given that the fapa is operationally dependent on the availability the fapolicyd dbase, rules, and config files, and secondarily, the fapolicy-analyzer is now available via standard Fedora and RHEL repos. In lieu (or in addition?) of that, I think the dialog messaging should swap the first two possible causes, so that the installation of fapolicyd is the first item to verify.
2. Aborted sessions were handled as expected with a dialog presented to the user notifying them of the existence of a prior session. Choose the delayed restore session work-flow and noticed no issues.
3. Modified the fapolicyd config file such that the syslog output format has the supported uid,gid, for auid, substitution. The Save/Download icon button provided no persistence by saving to the config file or a temp file (ifaik) for later use. The write to the config file only occurs upon deployment.
4. Ran the profiler a number of times, and in general it worked correctly and as expected. I did see a couple of failures though. I originally thought that args were not being parsed/handled correctly and attempted to dup or localize the failure but could not reproduce. I did have debug logging on though for one of the failures and it to be related to not being able to get the fapolicyd state. Here is a snippet from the debug logging:

DEBUG:root:Entry text = {'cmd': 'my-ls', 'arg': '-l', 'uid': 'toma', 'pwd': '/tmp', 'env': 'PATH=$PATH:', 'pwd_ui': '/tmp', 'env_dict': {'PATH': '/usr/sbin:/usr/bin:/sbin:/bin:/root/bin:/tmp'}}
DEBUG:root:dispatch( START_PROFILING_REQUEST )
DEBUG:fapolicy_pyo3.profiler:set_user: looking up username toma
DEBUG:fapolicy_pyo3.profiler:profile_all my-ls -l
DEBUG:root:_status(ServiceStatus.FALSE updated
DEBUG:root:monitor_daemon:Dispatch update request
DEBUG:root:on_update_daemon_status(ServiceStatus.FALSE)
DEBUG:root:_update_fapd_status(ServiceStatus.FALSE)
WARNING:fapolicy_daemon.profiler:wait_until_ready failed
thread '' panicked at 'profiling failure: "failed to observe fapolicyd ready state"', crates/pyo3/src/profiler.rs:284:27
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace
INFO:root:validateArgs()
DEBUG:root:validateArgs({'cmd': 'my-ls', 'arg': '-l', 'uid': 'toma', 'pwd': '/tmp', 'env': 'PATH=$PATH:.'}

Is it possible that the independent fapd status thread could be attempting to get daemon status in approximately the same time window and the query/response sequencing of the overlapping requests (on separate threads) are affecting a common global variable. And as always, Or not...

DEBUG:root:dispatch( START_PROFILING_REQUEST ) # Primary thread dispatches via redux to eventually request state via Rust
...
DEBUG:root:_status(ServiceStatus.FALSE updated
DEBUG:root:monitor_daemon:Dispatch update request # Monitoring thread concurrently requesting fapd state via Rust layer.
...
DEBUG:root:_update_fapd_status(ServiceStatus.FALSE)
WARNING:fapolicy_daemon.profiler:wait_until_ready failed

I'll look at the code wrt how the fapd monitoring is currently done, i.e. if it's still done using an independent polling thread.

Otherwise and overall, for FC38 things look good.

[jw3]

... I think the dialog messaging should swap the first two possible causes, so that the installation of fapolicyd is the first item to verify.

Makes sense to swap those.

[tparchambault]

On FC39:

1. Blank screen start-up, although the Tool menu works and I can select another tool and it will render:
   

It appears that there is a Gtk issue, based on:

gi.repository.GLib.GError: gtk-builder-error-quark: .:31:1 Invalid object type 'GtkSourceView' (6)

Hopefully we are just missing a py pkg. The debug log is attached.
FC39_blank_start_up.txt

I'll research if my FC39 platform is current. It was created using a rawhide iso a few months ago. I won't assume updates were applied to make it current. Stay tuned...

[tparchambault]

The good news is that applying all recent updates to the Fc39/rawhide platform has addressed the above Gtk runtime issue. Will continue testing.

In summary on FC39, tested:

1. The Profiler works as expected w/a copy of /usr/bin/ls in /tmp w/the PATH env var set to PATH=$PATH: Executed the analysis icon button and the results of my profiling run were displayed as expected.
2. Terminated user session w/KILL -9` with pending changesets that would modify the Ancillary Trust dbase. Aborted session was detected providing the user w/the option of loading the prior session. Loading that session worked w/o issue.
3. Saved a session w/o deploying. Open that session file on a subsequent run. It loaded w/o any observed issues. The fapd remained stopped as expected.
4. Exercised the daemon control functionality w/o issue.
5. I did not exercise rule editing nor rule deployment.

[tparchambault]

Tested over RHEL 9.2. TLDR No repeatable or significant issues observed. One intermittent observation that I have seen before, but it was also intermittent at that time (see below):

1. Updated pkgs prior to installing the fapolicy-analyzer pkg.
2. Exercised the Ancillary Trust view. Added a local config file, # kill -9 PID prior to deploying to test the aborted session detection and restore functionality. No issues observed.
3. Modified the fapolicyd.conf file via the embedded editor to the required logging format. Saved and deployed changes. No issues observed.
4. Exercised the profiler by copying the /usr/bin/ls executable to /tmp. Fully populated the view and ran multiple tests, e.g. CL options, env vars, root user and non-root user, modifying the working dir, etc. No issues observed.
5. Cursory testing of the Daemon start/stop functionality. There were occasions when the fapolicyd did not start/stop as directed via the requested menu item. In the prior instances, that I have observed this, the tool was performing a background function e.g. getting the initial System object creating and display of the System Trust list. Could not duplicate, so ultimately anomaly may be anecdotal and/or probabilistic in nature.

[jw3]

#917 is a blocker related to saved sessions

[tparchambault]

On an FC38 via an ssh session, attempting to invoke the embedded help system resulted in a program crash with the following logging messages:

DEBUG:root:loading help from help:fapolicy-analyzer/User-Guide.html
libEGL warning: DRI2: failed to authenticate

(-m:3437): Gdk-WARNING **: 13:30:50.569: The program '-m' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadRequest (invalid request code or no such operation)'.
  (Details: serial 92153 error_code 1 request_code 154 (unknown) minor_code 1)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the GDK_SYNCHRONIZE environment
   variable to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)
Terminating pkttyagent.
[toma@fedora ~]$

Will check on FC39 and Rhel92 to determine if the symptom is limited to only FC38.

[tparchambault]

Duplicated on FC39, i.e. embeded Help works correctly in Desktop session, immediate termination when invoked in ssh session.

DEBUG:root:loading help from help:fapolicy-analyzer/User-Guide.html
libEGL warning: DRI2: failed to authenticate

(-m:1733): Gdk-WARNING **: 18:15:33.536: The program '-m' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadRequest (invalid request code or no such operation)'.
  (Details: serial 214468 error_code 1 request_code 154 (unknown) minor_code 1)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the GDK_SYNCHRONIZE environment
   variable to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)
Terminating pkttyagent.
[toma@fedora ~]$

Also moved selinux into permissive mode without observing a change in the symptom.

[tparchambault]

Wrt libEGL warning: DRI2: failed to authenticate, this is a non-fatal event. In the localization process, I've use gnome-tour over ssh w/X forwarding and see this warning however the app executes correctly.

[tparchambault]

The good news is that the embedded help worked on RHEL 9.2. The following is the log messages associated with that run after invoking the help system from the Help menu.

DEBUG:root:loading help from help:fapolicy-analyzer/User-Guide.html

** (WebKitWebProcess:60254): WARNING **: 19:27:42.095: Can't connect to a11y bus: Could not connect: Connection refused

Iirc, FCxx has a different version of WebKit. Will research and/or verify the FCxx installations have User-Guide.html in the expected location.

[tparchambault]

More good news. The embedded help works on an ssh session over RHEL 8.6

[tparchambault]

No luck with localizing to a definitive root cause. I'm going to put the offending code in a try/except block with appropriate logging so that invoking the embedded help doesn't result in an application termination and allows the user to continue.

Edit: No exceptions thrown, so no exceptions to catch. Continuing the debugging.

[tparchambault]

Compared the FC38 development vs production (rpm install) environments and the same X System Error messaging was displayed, however the production installed also displayed this addtional msg, Terminating pkttyagent. while terminating the fapolicy-analyzer while the development environment execution doesn't terminate. Looking at polkit and Gtk/WebKit versioning between the good RHEL8/9 and the bad FC38/39 embedded help over ssh.

The good RHEL 9.2 polkit and webkit pkgs:

[toma@rhel92-testbed ~]$ rpm -qa | grep polkit
polkit-libs-0.117-11.el9.x86_64
polkit-0.117-11.el9.x86_64
polkit-pkla-compat-0.1-21.el9.x86_64
[toma@rhel92-testbed ~]$ rpm -qa | grep -i webkit
libproxy-webkitgtk4-0.4.15-35.el9.x86_64
webkit2gtk3-jsc-2.38.5-1.el9_2.3.x86_64
webkit2gtk3-2.38.5-1.el9_2.3.x86_64
[toma@rhel92-testbed ~]$

The bad FC38 polkit and webkit pkgs:

[toma@fedora38 ~]$ rpm -qa | grep polkit
polkit-pkla-compat-0.1-23.fc38.x86_64
polkit-libs-122-3.fc38.1.x86_64
polkit-122-3.fc38.1.x86_64
[toma@fedora38 ~]$ rpm -qa | grep -i webkit
webkit2gtk4.1-2.42.1-1.fc38.x86_64
webkitgtk6.0-2.42.1-1.fc38.x86_64
webkit2gtk4.0-2.42.1-1.fc38.x86_64
[toma@fedora38 ~]$

Based on the above, at the highest level and assuming that the Fedora pkg naming convention maps -122 to -0.122, it appears that FC38 versions have been bumped from polkit 117 to polkit 122, and from Gtk3 to Gtk4. So that's a couple of possibilities to research.

[jw3]

This can be resolved with #824

• Use Yelp by default #824

You should open a bug with the above details, and reference #824 from it.

[tparchambault]

#922 opened.

[tparchambault]

Other than the previously mentioned embedded help over ssh issue over FC38 and FC39/rawhide:

• FC38: Tested fapd control, profiler (w/PATH env var set), session crash/detection on restart/restore, explicit session save/open, edited/deployed fapd config file. No issues observed.
• FC39: Ditto wrt tests. Observed some issues with controlling the fapd when deploying the modified fapd config changeset. Beyond that, no significant functional issues observed.
• RHEL 9.2: Ditto wrt tests. No significant functional issues observed, but also observed intermittent fapd comm and deployment issues, e.g. Iirc, the following was a deploy after the restore of an interrupted user session:

DEBUG:fapolicy_pyo3.system:config_text
DEBUG:fapolicy_pyo3.system:config_text
DEBUG:root:Deploying...
DEBUG:root:dispatch( DEPLOY_SYSTEM )
INFO:root:fapd_dbase::fapd_dbase_snapshot()
Fapolicyd backup to: /var/lib/fapolicy-analyzer/Fapolicyd_Backup_20231012_111116_482440.tgz
INFO:root:fapd_dbase_cleanup_snapshots()
DEBUG:root:Search Pattern: /var/lib/fapolicy-analyzer/Fapolicyd_Backup_*.tgz
DEBUG:root:Glob search results: ['/var/lib/fapolicy-analyzer/Fapolicyd_Backup_20231012_103800_967983.tgz', '/var/lib/fapolicy-analyzer/Fapolicyd_Backup_20231012_104254_360077.tgz', '/var/lib/fapolicy-analyzer/Fapolicyd_Backup_20231012_111116_482440.tgz']
DEBUG:fapolicy_pyo3.system:deploy
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:fapolicy_daemon.svc:waiting on fapolicyd to be Active...
DEBUG:fapolicy_daemon.svc:waiting on fapolicyd to be Active...
DEBUG:fapolicy_daemon.svc:waiting on fapolicyd to be Active...
DEBUG:fapolicy_daemon.svc:waiting on fapolicyd to be Active...
...

After these types of fapd control comm issues, subsequent interactions with the fapd fail. This may be a dbus level failure, or possibly our Redux/state management doesn't handle the comms failure gracefully and is in an expected state but I'm speculating. Will continue monitoring and collecting datapoints to provide a consistent workflow that creates the failure.

[jw3]

What do you see if you systemctl status fapolicyd while we are "waiting"?

[tparchambault]

I'll check next time I observe it.

[tparchambault]

I've occasionally seen references in the past about not being able to write the pid file in the output to # systemctl status fapolicyd. Today, I've pulled the following from the journal:

[toma@localhost ~]$ journalctl -f -u dbus.service 
-- Logs begin at Thu 2023-10-12 13:36:08 EDT. --
Oct 12 16:26:51 localhost.localdomain dbus-daemon[916]: [system] Activating service name='org.fedoraproject.Setroubleshootd' requested by ':1.3273' (uid=0 pid=884 comm="/usr/sbin/sedispatch " label="system_u:system_r:auditd_t:s0") (using servicehelper)
Oct 12 16:26:54 localhost.localdomain dbus-daemon[916]: [system] Successfully activated service 'org.fedoraproject.Setroubleshootd'
Oct 12 16:26:56 localhost.localdomain setroubleshoot[25225]: AnalyzeThread.run(): Cancel pending alarm
Oct 12 16:26:57 localhost.localdomain dbus-daemon[916]: [system] Activating service name='org.fedoraproject.SetroubleshootPrivileged' requested by ':1.3285' (uid=980 pid=25225 comm="/usr/libexec/platform-python -Es /usr/sbin/setroub" label="system_u:system_r:setroubleshootd_t:s0-s0:c0.c1023") (using servicehelper)
Oct 12 16:26:59 localhost.localdomain dbus-daemon[916]: [system] Successfully activated service 'org.fedoraproject.SetroubleshootPrivileged'
Oct 12 16:27:07 localhost.localdomain setroubleshoot[25225]: SELinux is preventing fapolicyd from write access on the file fapolicyd.pid. For complete SELinux messages run: sealert -l 10a0f774-f3ad-4bf6-aba8-f70a4cb3b386
Oct 12 16:27:07 localhost.localdomain setroubleshoot[25225]: SELinux is preventing fapolicyd from write access on the file fapolicyd.pid.
                                                             
    *****  Plugin catchall (100. confidence) suggests   **************************
                                                             
    If you believe that fapolicyd should be allowed write access on the fapolicyd.pid file by default.
    Then you should report this as a bug.
    You can generate a local policy module to allow this access.
    Do allow this access for now by executing:
          # ausearch -c 'fapolicyd' --raw | audit2allow -M my-fapolicyd
          # semodule -X 300 -i my-fapolicyd.pp
                                                             
Oct 12 16:27:07 localhost.localdomain setroubleshoot[25225]: AnalyzeThread.run(): Set alarm timeout to 10
Oct 12 16:53:09 localhost.localdomain dbus-daemon[916]: [system] Activating via systemd: service name='org.freedesktop.hostname1' unit='dbus-org.freedesktop.hostname1.service' requested by ':1.3931' (uid=0 pid=25076 comm="python3 -m fapolicy_analyzer.ui -a -vv " label="unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023")
Oct 12 16:53:11 localhost.localdomain dbus-daemon[916]: [system] Successfully activated service 'org.freedesktop.hostname1'

Why SELinux is only occasionally prohibiting this write is beyond me. From the audit log:

[toma@localhost ~]$ sudo ausearch -m AVC
[sudo] password for toma: 
----
time->Thu Oct 12 16:26:48 2023
type=PROCTITLE msg=audit(1697142408.105:287): proctitle="/usr/sbin/fapolicyd"
type=SYSCALL msg=audit(1697142408.105:287): arch=c000003e syscall=257 success=no exit=-13 a0=ffffff9c a1=556294101b7a a2=20241 a3=1a4 items=0 ppid=1 pid=25215 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="fapolicyd" exe="/usr/sbin/fapolicyd" subj=system_u:system_r:fapolicyd_t:s0 key=(null)
type=AVC msg=audit(1697142408.105:287): avc:  denied  { write } for  pid=25215 comm="fapolicyd" name="fapolicyd.pid" dev="tmpfs" ino=146254 scontext=system_u:system_r:fapolicyd_t:s0 tcontext=unconfined_u:object_r:var_run_t:s0 tclass=file permissive=0
[toma@localhost ~]$

[tparchambault]

RHEL 8.6: Attempted to edit the fapd config file ( via Daemon > Config) which failed as follows:

DEBUG:root:_PostInitCaller.__call__((), {})
Traceback (most recent call last):
  File "/usr/lib64/python3.6/site-packages/fapolicy_analyzer/ui/main_window.py", line 454, in on_configAdminMenu_activate
    self.__pack_main_content(router(PAGE_SELECTION.CONFIG))
  File "/usr/lib64/python3.6/site-packages/fapolicy_analyzer/ui/main_window.py", line 78, in router
    return route(*data)
  File "/usr/lib64/python3.6/site-packages/fapolicy_analyzer/ui/ui_widget.py", line 40, in __call__
    obj = type.__call__(cls, *args, **kwargs)
  File "/usr/lib64/python3.6/site-packages/fapolicy_analyzer/ui/config_admin_page.py", line 50, in __init__
    UIConnectedWidget.__init__(self, features=features)
  File "/usr/lib64/python3.6/site-packages/fapolicy_analyzer/ui/ui_widget.py", line 122, in __init__
    UIBuilderWidget.__init__(self)
  File "/usr/lib64/python3.6/site-packages/fapolicy_analyzer/ui/ui_widget.py", line 93, in __init__
    self._builder.add_from_string(glade)
  File "/usr/lib64/python3.6/site-packages/gi/overrides/Gtk.py", line 465, in add_from_string
    return Gtk.Builder.add_from_string(self, buffer, length)
GLib.Error: gtk-builder-error-quark: .:21:1 Required gtk+ version 3.24, current version is 3.22 (7)

[jw3]

GLib.Error: gtk-builder-error-quark: .:21:1 Required gtk+ version 3.24, current version is 3.22 (7)

Looks like the config glades got set to 3.24, all other glades are 3.22.

https://github.com/search?q=repo%3Actc-oss%2Ffapolicy-analyzer%203.24&type=code

[tparchambault]

Manually edited /usr/lib64/python3.6/site-packages/fapolicy_analyzer/glade/config_admin_page.glade and /usr/lib64/python3.6/site-packages/fapolicy_analyzer/glade/config_text_view.glade which addressed the issue. Thx @jw3

[tparchambault]

#924

[jw3]

Should have a 1.2.0-rc3 soon.

There was a crate update across fc* and el9 that broke our build while it was progressing to stable. That update is now stable everywhere exception fc39, which is waiting on fc39 itself to be stable (10-31). The RC3 build is going to be short the fc39 release artifacts.

[jw3]

Again, for posterity, the best thing to do is avoid releasing our software at the same time Fedora is rolling a release. Easy to plan on that, their schedule is consistent.

Fedora creates two major OS releases every year, targeted for the fourth Tuesday in April and October. We don’t follow a strict "ship on this date!" policy, nor do we wait until every single possible thing is perfect. Fedora integrates thousands of always-changing upstream packages, and if we stuck to a date no matter what, we’d always ship with serious bugs, and if we attempted to squash every problem before releasing, we’d never ship at all.

To understand more about the reasoning behind Fedora’s process and release life cycle, see the Release Life Cycle documentation.

https://docs.fedoraproject.org/en-US/releases/#_our_release_schedule

schedule for 39

https://fedorapeople.org/groups/schedule/f-39/f-39-key-tasks.html

[jw3]

Rc3 is available 🎉

[tparchambault]

Excellent.

[tparchambault]

Testing over FC38:

1. Observation (Non-issue): [Menu] Daemon > Config. The associated config editor appears to use the same text high-lighting map as the rules editor. Can / Should this be disabled since the high-lighting in the config editor is incorrect?
2. Possible Issue: Tested config editor to modify the syslog_format followed w/save operation - Observed four times that if I navigate away from the config editor after a save (w/o a deploy) to the trust tool, and then return to the config editor, then deploy (accepting the new state), then attempt to navigate back to the trust tool (post successful deploy), I get prompted with the Unsaved Changes dlg although I made no changes.
3. Exercised start/stop daemon - No issues observed.

Wrt item 2 above:

DEBUG:fapolicy_pyo3.system:deploy
DEBUG:fapolicy_daemon.svc:waiting on fapolicyd to be Inactive...
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:fapolicy_daemon.svc:fapolicyd is now Active
DEBUG:root:dispatch( ADD_NOTIFICATION )
DEBUG:root:dispatch( SET_SYSTEM_CHECKPOINT )
DEBUG:root:dispatch( CLEAR_CHANGESET )
INFO:root:SessionManager::autosave_edit_session()
DEBUG:root:  Writing to: /var/lib/fapolicy-analyzer/fapolicy-analyzer.tmp_20231030_132528_046767.json
DEBUG:root:Path/Action Dict: []
INFO:root:SessionManager::save_edit_session(/var/lib/fapolicy-analyzer/fapolicy-analyzer.tmp_20231030_132528_046767.json)
DEBUG:root:['/var/lib/fapolicy-analyzer/fapolicy-analyzer.tmp_20231030_125810_308943.json', '/var/lib/fapolicy-analyzer/fapolicy-analyzer.tmp_20231030_132528_046767.json']
DEBUG:root:dispatch( REQUEST_CONFIG_TEXT )
DEBUG:fapolicy_pyo3.system:config_text
DEBUG:root:dispatch( MODIFY_CONFIG_TEXT )
DEBUG:root:dispatch( MODIFY_CONFIG_TEXT )
DEBUG:fapolicy_pyo3.system:config_info
DEBUG:root:disposing of subscription for class DeployChangesetsOp
DEBUG:root:dispatch( REMOVE_NOTIFICATION )
DEBUG:root:_PostInitCaller.__call__((), {})
DEBUG:root:dispatch( REQUEST_ANCILLARY_TRUST )
DEBUG:root:_PostInitCaller.__call__((), {})
DEBUG:root:dispatch( REQUEST_SYSTEM_TRUST )

I believe that these two dispatch statement are superfluous (or the log string is incorrect0. No explicit user actions occurred post-deploy and accepting the new state:

DEBUG:root:dispatch( MODIFY_CONFIG_TEXT )
DEBUG:root:dispatch( MODIFY_CONFIG_TEXT )

[jw3]

PR #935 for #2

[tparchambault]

Thx @jw3 for looking into this.

[jw3]

#937 for the syntax highlighting

[jw3]

@tparchambault thanks for testing.

RC4 is baking now and will include fixes for 1 and 2

[jw3]

The v1.2.0-rc4 release needed a rebuild, running now.

[tparchambault]

Issue is not restricted to the daemon config editor, it appears.

Profiled a copy of ls in my HOME dir. Executed w/o issue; Attempted to analyze the results and got the following exception and stack:

DEBUG:root:_make_profiling_args(): expanded w/env dict = {'cmd': 'myls', 'arg': '-l', 'uid': 'toma', 'pwd': '/tmp', 'env': 'PATH=$PATH:$HOME', 'pwd_ui': '/tmp', 'env_dict': {'PATH': '/usr/sbin:/usr/bin:/sbin:/bin:/root/bin:/home/toma'}}
DEBUG:root:Entry text = {'cmd': 'myls', 'arg': '-l', 'uid': 'toma', 'pwd': '/tmp', 'env': 'PATH=$PATH:$HOME', 'pwd_ui': '/tmp', 'env_dict': {'PATH': '/usr/sbin:/usr/bin:/sbin:/bin:/root/bin:/home/toma'}}
DEBUG:root:dispatch( START_PROFILING_REQUEST )
DEBUG:fapolicy_pyo3.profiler:set_user: looking up username toma
DEBUG:fapolicy_pyo3.profiler:profile_all myls -l
DEBUG:root:_PostInitCaller.__call__((False, '/var/tmp/.fapa1698696504.events'), {})
DEBUG:root:dispatch( REQUEST_USERS )
DEBUG:fapolicy_pyo3.system:users
DEBUG:root:dispatch( REQUEST_GROUPS )
DEBUG:fapolicy_pyo3.system:groups
DEBUG:root:dispatch( REQUEST_EVENTS )
DEBUG:fapolicy_pyo3.system:load_debuglog
DEBUG:root:dispatch( REQUEST_USERS )
DEBUG:fapolicy_pyo3.system:users
DEBUG:root:dispatch( REQUEST_GROUPS )
DEBUG:fapolicy_pyo3.system:groups
DEBUG:root:dispatch( REQUEST_EVENTS )
DEBUG:fapolicy_pyo3.system:load_debuglog
Traceback (most recent call last):
  File "/usr/lib64/python3.11/site-packages/fapolicy_analyzer/ui/profiler_page.py", line 198, in on_analyzer_button_clicked
    self.analyze_button_pushed(self.analysis_file)
  File "/usr/lib/python3.11/site-packages/events/events.py", line 27, in __call__
    f(*a, **kw)
  File "/usr/lib64/python3.11/site-packages/fapolicy_analyzer/ui/main_window.py", line 473, in activate_file_analyzer
    self.__pack_main_content(page)
  File "/usr/lib64/python3.11/site-packages/fapolicy_analyzer/ui/main_window.py", line 180, in __pack_main_content
    if hasattr(self.__page, "_unsaved_changes") and self.__page._unsaved_changes:
       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/site-packages/events/events.py", line 93, in __getattr__
    raise EventsException("Event '%s' is not declared" % name)
events.events.EventsException: Event '_unsaved_changes' is not declared

[jw3]

Yeah I didnt add an issue for that and never saw that exception while testing and then forgot about it.

It is unrelated to the two issues that were fixed, so you should be able to test those while I address this one.

[jw3]

#940 Simply navigate to the profiler and then away from it, no execution of the profiler is required.

There was an introspective check added in #921 that looks in a ui page for a dirty flag. It's not obvious why that is failing in this case, but it appears to be the cause.

[jw3]

#941 fixes the navigation. The fix is not obviously applicable, but the root cause is the introspection being used to check the dirty state. We should review that and consider a more concrete mechanism to check dirty state.

[jw3]

rc5 is building ... and done

[tparchambault]

Gracias @jw3