Plasma Firewall on KDE Review

Kevin Kofler kevin.kofler at
Tue Jan 26 16:15:47 GMT 2021


Am Dienstag, 26. Jänner 2021 16:17:27 CET schrieb Tomaz Canabrava:
> There's one thing that's a bit annoying while working on firewalld:
> ~ on  master ⌚ 15:08:53
> $ firewalld --help
> You need to be root to run /usr/bin/firewalld.

firewalld starts the actual daemon, which needs to run as root. The way to
interact with the daemon (which may or may not require root permissions
depending on what you want to do with it and on what PolicyKit policies are
set) is using the firewall-cmd command. (That, or just use the D-Bus 
directly, which is all firewall-cmd does. You'd avoid having to scrape CLI
output that way.)

There is also the firewall-offline-cmd command, which has limited support 
configuring firewalld without talking to an actual firewalld instance. This 
mainly designed for installers and other chroot environments. But
firewall-offline-cmd always needs root permissions.

firewall-cmd --get-services
gets me a list of available services, and does not require root at least 
me. (I get neither an error message nor a PolicyKit password prompt.)

Note that this is NOT the same as:
firewall-cmd --list-services
which is the list of services actually enabled (allowed) in the currently
enabled zone, and which automatically brings up a PolicyKit prompt for a 
password before returning the list.

Also note that a firewalld service is not necessarily just a list of ports.
Firewalld also supports "protocols", "modules", and "helpers", which are
dynamic firewall rules. (That is the main reason why the userspace daemon 
needed at all.) So there are services (e.g., samba) for which you will not 
able to generate rules in your existing internal (iptables-like) format, 
will only fully work if you actually use the service name.

Try, e.g.:
firewall-cmd --info-service=ssh
firewall-cmd --info-service=samba
(which bring up a PolicyKit password prompt) to see what those services
actually are. (But as I explained above, Plasma Firewall should not 
use that, it should just directly enable the service by its name.)

        Kevin Kofler

More information about the kde-core-devel mailing list