Refactor polkit configuration

[54m43lJ]

Is your feature request related to a problem? Please describe. I find the application repeatedly asking for authentication each time it does something (e.g. refreshing) annoying.

Describe the solution you'd like Something persistent that authenticates once and a) wakes up after a given interval and pushes information to the frontend, or b) runs like a background service that has some APIs you can call.

Describe alternatives you've considered None.

Additional context None.

It's a lot of work, but this mildly infuriating quirk is just driving me nuts and I really wanna see it gone.

I imagine it can simply become a daemon program that listens on a socket or something. This has other implications too: we can turn this into a full blown AppAnvil service that handles all the privileged code.

For example, the current log parsing works on Ubuntu because the user account is assigned adm group which grants the user read permission to kernel log files. However, in Arch Linux those logs go to systemd, and they are not stored in plaintext format unless you enable the auditing framework, in which case the logs are stored in /var/log/audit/audit.log, only accessible to the root user. So for maximum compatibility the log reading code should ideally be run by root user and separate from the graphical interface.

[54m43lJ]

Also a side note, in the future this can double as a utility program for some extra hackery, which I'd love to see. Being able to run this as normal user instead of sudo aa-logprof is another plus.

Like, imagine how cool you must feel when you type aa-caller logs instead of clicking around the Logs tab like a scrub.

[jack-ullery]

It certainly should not be asking you for authentication every time it refreshes. That sounds super annoying! This is something we originally fixed early on in the project when we implemented our custom pkexec policy.

Looking at the code for that, I can see a potential issue: https://github.com/jack-ullery/AppAnvil/blob/24881f3f2b03b93aac02446a739e137bf005cc76/resources/pkexec.policy.in#L13C1-L13C104

The pkexec policy only activates for the installed version of AppAnvil (at /usr/bin/appanvil), not the local development build. Furthermore, this policy itself needs to be installed (with sudo make install)

A future change could change the value in the policy to point to both the develop build (only during development) and the installed appanvil (at /usr/bin)

Or, maybe pkexec policy not work the same on your version of Arch (here's the wiki).

[jack-ullery]

Also a side note, in the future this can double as a utility program for some extra hackery, which I'd love to see. Being able to run this as normal user instead of sudo aa-logprof is another plus.

Like, imagine how cool you must feel when you type aa-caller logs instead of clicking around the Logs tab like a scrub.

After running sudo make install, you should be able to run pkexec aa-caller -l (which honestly should probably be renamed to aa-caller logs).

[54m43lJ]

It certainly should not be asking you for authentication every time it refreshes. That sounds super annoying! This is something we originally fixed early on in the project when we implemented our custom pkexec policy.

Looking at the code for that, I can see a potential issue: https://github.com/jack-ullery/AppAnvil/blob/24881f3f2b03b93aac02446a739e137bf005cc76/resources/pkexec.policy.in#L13C1-L13C104

The pkexec policy only activates for the installed version of AppAnvil (at /usr/bin/appanvil), not the local development build. Furthermore, this policy itself needs to be installed (with sudo make install)

A future change could change the value in the policy to point to both the develop build (only during development) and the installed appanvil (at /usr/bin)

Or, maybe pkexec policy not work the same on your version of Arch (here's the wiki).

I think you're spot on about pkexec being the root issue. However I see two problems with the current approach: 1. auth_admin_keep only grants you 5 min of elevated privileges, combine that with the regular refreshing is why it keeps popping up (not an Arch issue btw), and I've yet to find a configuration that can grant privilege once and keep it forever (which would be very unsafe?) 2. I see code for reading from auditd logs but no logs were read unless I run appanvil as superuser with sudo -E appanvil, so something must be wrong here.

[jack-ullery]

Reacting to your previous comment

However, in Arch Linux those logs go to systemd, and they are not stored in plaintext format unless you enable the auditing framework, in which case the logs are stored in /var/log/audit/audit.log, only accessible to the root user. So for maximum compatibility the log reading code should ideally be run by root user and separate from the graphical interface.

This is an separate issue (which is also important). We actually used to read the logs from systemd using journalctl, but I stopped for whatever reason (can't remember why - maybe some conflict with auditd).

We have some implementation to read and parse auditd logs, which is currently being done as the root user separate from the GUI (that's the point of aa-caller). One potential issue could come from the fact that we currently are reading a few logs from the GUI as a non-root user: /var/log/kern.log, /var/log/dmesg, /var/log/syslog.

Now for your new comment:

I think you're spot on about pkexec being the root issue. However I see two problems with the current approach: 1. auth_admin_keep only grants you 5 min of elevated privileges, combine that with the regular refreshing is why it keeps popping up (not an Arch issue btw), and I've yet to find a configuration that can grant privilege once and keep it forever (which would be very unsafe?)

I think our original idea was to try and approximate the behavior of sudo (which I see now stores credentials for 15 minutes). We can make this longer or even indefinite, which I don't see much of a problem with because this utility is only used for reading logs and other similar data (but greater minds may differ on the impact)

2. I see code for reading from auditd logs but no logs were read unless I run appanvil as superuser with sudo -E appanvil, so something must be wrong here.

I think your right and something got messed up with this somewhere, because it's not working for me either. This is definitely worth exploring, even if we go back to the journalctl implementation.

[jack-ullery]

I see now that the auth_admin_keep is hardcoded to 5 minutes (unless on OpenSUSE). There might be another approach with polkit authorization rules, but I think the log issue is higher priority for me right now.