This PR fixes the issue described in #31, by changing the layout of the Logs tab.
Change 1: - Create separate pane for Logs tab
The main problem, was that the log data to display depends on the type of log that is displaying. For example, logs with a DENIED type will need to display different values than logs of STATUS type.
For example, we want to list the denied resource for some DENIED events, but where in the TreeView should we put that information? Furthermore unlike some STATUS logs, there is no "Status" information to display, which makes that column meaningless.
To solve this, I created a separate pane, similar to the one on the Profiles tab. When a row is selected, this separate pane will dynamically populate important information about the row, that could not be included in the TreeView.
Here is are some example screenshots:
Change 2: - Create invisible column in TreeView
To the information in the Logs pane, I needed to store additional information about a log inside a TreeRow. To achieve this. I created an invisible column in the TreeView, with a custom CellRenderer, which can store the LogEntry struct. Now, it is possible to set and retrieve from a row, by accessing the value at the zeroth column.
I also created similar invisible columns for the TreeViews in the Profiles and Processes tab. This setup leads to performance improvements when retrieving TableEntry structs for selected rows. Instead of performing a logarithmic operation to retrieve the entry for a row, it should now take constant time.
Other comments
I did not exhaustively test these changes on every possible type of log emitted by AppArmor. Many types of logs are not supported yet.
I found that the libapparmor package provides functionality for parsing logs to a C struct. This promises to be much faster than our current implementation, and should be seriously considered in the future. The only problem, is that I cannot seem to generate logs in the correct format. When testing with logs from their repositories test-suite, this library works perfectly. However, when using logs generated by journalctl or ausearch, I run into problems. More research will need to be done before we can use this library for log parsing. Most of my experimentation be found on this branch.
Description
This PR fixes the issue described in #31, by changing the layout of the Logs tab.
Change 1: - Create separate pane for Logs tab
The main problem, was that the log data to display depends on the type of log that is displaying. For example, logs with a DENIED type will need to display different values than logs of STATUS type.
For example, we want to list the denied resource for some DENIED events, but where in the TreeView should we put that information? Furthermore unlike some STATUS logs, there is no "Status" information to display, which makes that column meaningless.
To solve this, I created a separate pane, similar to the one on the Profiles tab. When a row is selected, this separate pane will dynamically populate important information about the row, that could not be included in the TreeView.
Here is are some example screenshots:
Change 2: - Create invisible column in TreeView
To the information in the Logs pane, I needed to store additional information about a log inside a TreeRow. To achieve this. I created an invisible column in the TreeView, with a custom CellRenderer, which can store the LogEntry struct. Now, it is possible to set and retrieve from a row, by accessing the value at the zeroth column.
I also created similar invisible columns for the TreeViews in the Profiles and Processes tab. This setup leads to performance improvements when retrieving TableEntry structs for selected rows. Instead of performing a logarithmic operation to retrieve the entry for a row, it should now take constant time.
Other comments
journalctlorausearch, I run into problems. More research will need to be done before we can use this library for log parsing. Most of my experimentation be found on this branch.