Fedora Linux Errors

[klimpix 0]

Hi,

I’m currently testing AirVPN/Eddie on Fedora 44 with KDE Plasma/Wayland and SELinux enforcing. I have run into two issues that seem Fedora/Linux specific.

The main problem concerns the option “Don’t ask elevation every run.”

If this option is disabled, Eddie works normally: I enter my password once, Network Lock works, and the VPN connection is established without problems.

If I enable “Don’t ask elevation every run”, Eddie installs/uses the persistent systemd elevated helper, but after reboot Network Lock fails and Eddie is unable to connect.

I already added the recommended firewalld setting:

NftablesTableOwner=no

to:

/etc/firewalld/firewalld.conf and restarted firewalld.

SELinux appears to be blocking the persistent elevated helper. Relevant AVC messages include:

avc: denied { rename } for comm="eddie-cli-eleva" scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:net_conf_t:s0 tclass=lnk_file

 

There are also denials involving cleanup of Eddie/systemd-resolved files:

avc: denied { unlink } for comm="eddie-cli-eleva" scontext=system_u:system_r:init_t:s0 tclass=file and nftables is denied access to the Network Lock backup file:

avc: denied { getattr } for comm="nft" path="/var/lib/eddie-vpn/state/netlock_nftables_backup.nft" scontext=system_u:system_r:iptables_t:s0 tclass=file

 

The Eddie state directory currently has root-only permissions:

/var/lib/eddie-vpn/state drwx------ root root

 

The visible Eddie error is essentially:

Could not open file: /var/lib/eddie-vpn/state/netlock_nftables_backup.nft Permission denied

I also tested the experimental Eddie 2.27 branch/version, but the behavior was unchanged.

As soon as I disable “Don’t ask elevation every run” again and use the normal password elevation method, the VPN and Network Lock work correctly. This makes it look like the persistent systemd helper does not currently integrate correctly with Fedora’s SELinux policy.

There is also a separate issue with KDE/Plasma: Eddie's icon in the taskbar does not work as expected. The “Minimize to the system tray” option is enabled in Eddie's settings, but when minimized, Eddie remains in the taskbar and does not minimize to the system tray.

My environment:

Fedora 44 KDE Plasma / Wayland SELinux: Enforcing firewalld: enabled NftablesTableOwner=no

I have intentionally omitted account information, VPN server names, IP addresses, hostnames and other identifying information. I can provide additional sanitized logs if needed.

Thanks

[Tech Jedi Alex 1579]

11 hours ago, klimpix said:

I can provide additional sanitized logs if needed.

Please do that, for completeness' sake. Close and reopen Eddie in a state which causes the error and try a connection once, then provide a system report:.

[klimpix 0]

Thanks, I had noticed the support feature as well. But I didn't want to open a support ticket for this since it's obviously just an issue with Eddie—or rather, the interaction between SELinux and Eddie itself. I thought I’d just post it here in the forum to bring it to people’s attention and let others who are affected know that they’re not alone :) I took a look at my system logs on Linux and saw that the problem is that Eddie’s persistent systemd helper isn’t properly packaged or integrated with SELinux policies on my Fedora 44. That’s why Eddie itself works, but the passwordless systemd version doesn’t—because Eddie, or rather the process, is trying to modify a protected path for which it simply lacks the necessary permissions. That’s also why it works without any issues without the systemd helper, since it accesses a different path. Do you see what I mean? I don’t think I need system support for this; rather, I think the technical team should try to reproduce the bug and then fix it in version 2.27 before it becomes stable. It was just meant as a note, but we’re welcome to discuss it further.

[greycoot454 0]

 

Tech Jedi Alex said:

Please do that, for completeness' sake. Close and reopen Eddie in a state which causes the error and try a connection once, then provide a system report. It’s the same reason I like a spinbaracasino to show clear game and slot information when something fails, because troubleshooting is a lot easier when you can actually see what happened.

 

Kinda smells like SELinux not liking the persistent helper after a reboot imo, curious what that report turns up.

Edited ... by greycoot454

[Staff 10691]

@klimpix
Hello!

Thank you for the report and clarification. This is the correct forum for such reports, of course.

The comparison between password-based elevation and the persistent systemd helper is useful. The reported SELinux denial involving nft and the Network Lock backup file points to an access issue in that execution context. However, the excerpts alone do not identify the required correction or the initial error preceding the failed restoration.

NftablesTableOwner=no addresses a separate issue, so there is no need to repeat that change.

To investigate further, please provide:

• The exact Eddie version and package source.
• A complete Eddie system report generated after reproducing the failure once with the persistent helper enabled.
• The complete SELinux audit events from the same attempt, including timestamps and source/target contexts, particularly the backup-file and rename/unlink denials.

Please keep SELinux and firewalld enabled. You may redact identifying information, but retain the relevant file paths, timestamps and SELinux contexts. In the meantime, you can continue using password-based elevation, which you report works correctly with Network Lock enabled.

The KDE system tray issue should be considered separately. Please also specify your Plasma version.

We can't confirm a correction or release timeframe at this stage but we will warn the developers expeditiously about this thread.

Kind regards
 

[klimpix 0]

@Staff
Hi,

I reproduced the issue again with the persistent elevation helper enabled.

I’m using Eddie 2.26.2 on Fedora 44 KDE, installed from the official RPM from eddie.website. Plasma is 6.7.5, I’m using Wayland, SELinux is enforcing and firewalld is enabled.

The problem is still the same. Network Lock fails and Eddie reports that it cannot open /var/lib/eddie-vpn/state/netlock_nftables_backup.nft because of a permission denied error.

I also checked the SELinux audit log from the same attempt. This time it only logged two rawip_socket denials for eddie-cli-eleva. The older additional SELinux denials involving nft and rename/unlink did not appear again in this run.

If I disable “Don’t ask elevation every run” and use the normal password prompt, Eddie still works fine, including Network Lock.

For the separate tray issue, I’m on Plasma 6.7.5 and “Minimize to system tray” is enabled, but the tray behavior still doesn’t work properly.

I attached the system report and the SELinux AVC output from this attempt. I redacted identifying and unnecessary network information, but left the relevant paths, timestamps, errors and SELinux contexts untouched.

Hope this helps you reproduce it.

eddie-selinux-avc-13-35-PUBLIC.txt Eddie-system-report-PUBLIC-REDACTED.txt

[Staff 10691]

@klimpix

Hello!

Thank you for providing the reports and the exact versions.

Your system report confirms that Eddie 2.26.2 is using the persistent helper and that Network Lock fails when nft attempts to read /var/lib/eddie-vpn/state/netlock_nftables_backup.nft. Before investigating further on 2.26.2, please test Eddie 2.27.2, currently available through the Experimental option on the download page. The 2.27 series includes corrections to systemd service creation, elevation failures caused by overly restrictive IPC directory permissions, and Network Lock failures when the shared state directory has been removed. These changes are documented in the changelog, although they do not establish that your particular issue is fixed.

You mentioned previously testing a 2.27 experimental build. Could you confirm its exact version? If it was already 2.27.2, please provide the report from that version; otherwise, please upgrade, reboot to ensure the persistent helper is restarted, and repeat the failing test with SELinux enforcing, firewalld enabled and Network Lock enabled. If it still fails, please attach a fresh system report and the corresponding AVC events, with the same privacy redactions.

The AVC attachment contains two denials for raw socket creation by the helper in the init_t domain. These confirm an SELinux restriction, but do not by themselves explain the backup-file access failure. The absence of the earlier file-related denials in this capture also does not rule out SELinux involvement.

In the meantime, you can continue using the password-based elevation method that you report works with Network Lock.

Thank you also for confirming Plasma 6.7.5 under Wayland. Please let us know whether the tray issue persists on 2.27.2. If so, we will keep it separate from the privileged-helper issue.

Kind regards
 

[klimpix 0]

@Staff
Hello
I tested again with Eddie 2.27.2 after upgrading and rebooting.

Unfortunately the issue is still present. Network Lock fails with the same permission denied error for /var/lib/eddie-vpn/state/netlock_nftables_backup.nft.

This time SELinux also showed the warning directly, and the AVC log contains the file-related denials again. In addition to the rawip_socket denials, there are rename/unlink denials involving resolv.conf and getattr denials for nft accessing netlock_nftables_backup.nft.

I attached a fresh Eddie 2.27.2 system report and the AVC events from the same attempt. SELinux is still enforcing and firewalld is still enabled. I only redacted identifying and unnecessary network information.

The tray issue also still persists on Plasma 6.7.5 under Wayland.

Hope this gives you a better reproduction of the problem.

Eddie-2.27.2-SELinux-AVC-PUBLIC-REDACTED.txt Eddie-2.27.2-system-report-PUBLIC-REDACTED.txt

[Staff 10691]

@klimpix

Hello!

Thank you for testing 2.27.2 after upgrading and rebooting. The updated reports confirm that the issue persists on your system.

The new AVC events directly document SELinux denying nft, running in the iptables_t domain, access to /var/lib/eddie-vpn/state/netlock_nftables_backup.nft. Their timestamps match the backup-file errors in Eddie’s log, during both startup recovery and subsequent Network Lock activation attempts. The helper also encounters separate denials involving DNS restoration and cleanup. This gives us clearer evidence of the SELinux access restrictions affecting the persistent-helper configuration. The exact correction still requires investigation into the helper’s execution context and the state files’ SELinux labels and permissions.

We will pass these updated reports to the developers for investigation. For now, please continue using password-based elevation, which you reported works with Network Lock, while keeping SELinux enforcing and firewalld enabled.

Thank you also for confirming that the tray issue persists with 2.27.2 on Plasma 6.7.5 under Wayland. We will include that information as a separate issue.

Kind regards
 

[klimpix 0]

@Staff

Glad I could help. Thanks for looking into it and passing the reports on to the developers. I’ll keep using password-based elevation for now and look forward to a fix in a future version.