since we’re making distinctions now … let’s not stop here …
competitive-online-gamers are most of the people that keep complaining on the purism forums that wifi and gaming is not a pleasant ENOUGH experience on open-hw/free-sw so they forget what this all is …
e-sports athletes are another thing entirely and so far i haven’t had the priviledge of talking to one here on the Purism forums … but who really knows this is the www after all …
Fair enough. Honestly, I’ve never liked wireless connections at all - whether it’s FOSS all the way down or covered by some 50 page legal agreement which demands the soul of your firstborn and the rights to everything you ever make, forever. A simple Ethernet cable does the job far better in pretty much every way.
I installed gufw from the store, yet when I try to run it, both through GUI and terminal it does not open and I am getting this error: 22:32:05 gnome-shell: /usr/bin/gufw-pkexec: line 13: 5296 Segmentation fault python3 ${LOCATIONS[${i}]} $1
does anyone know how I can remedy this issue? (pureos amber/librem 15v4)
So, to start diagnosing a segmentation fault, we usually need a stack trace. You can get it by running gdb --args $whatever-command-you-ran. Once gdb starts, type r, then once the program crashes, type bt. Paste the output someplace and we can take a look.
I really hope you’ll get an answer (output from gdb) from @skynet, but until then let me just think loudly (if not redundant, while not using it), gufw on Gnome and Xfce should work fine (just on Xorg, don’t know), with KDE Plasma some people reported that $ sudo gufw-pkexec works for them. But still, gufw / gui-ufw might not be friendly to Wayland (on top of Debian 10, maybe not as fine adjusted as when used with Ubuntu 20.04, which loads to Xorg display server by default), or rather vice versa. Again not sure, just trying to understand reasons why to push (or avoid) gufw on PureOS (even though not really looking to have/use optional graphical solution for UFW)?
How about to leave (remove) GUI-UFW aside and start from here:
$ sudo ufw --help
$ sudo ufw status
As well, I like this short article from 2018: “Wayland v/s Xorg: How Are They Similar & How Are They Different” (two approaches, even if not strictly on issue here).
So, if you’re on a Wayland compositor, you have to add root to the list of allowed users of your Xwayland X server.
Step 1: install xhost
Step 2: As the user who owns the $WAYLAND_DISPLAY socket, run xhost +SI:localuser:root
Step 3: Use sudo -i or su or whatever to switch to root.
Step 4: Run your command, if it will work with a remote X11 server, it should work with Xwayland.
Hm, haven’t gotten through the entire article yet, but there’s one fairly major technical problem with it in paragraph 3 (repeated later too). It says that in X-land, the window manager sits on top of the X server, and then your window (Firefox in their example) runs on top of the window manager. That is not the case. Your window manager runs on top of X, Firefox then runs on top of X, but X lets the window manager hijack Firefox’s draw commands and reroute them in order to decorate, position, and composite it. This is the central flaw with X11 which Wayland sets out to correct. Both in terms of performance, where opening gedit requires 70+ round-trip blocking calls to the X server, and in terms of security, where any application can act as a window manager, snooping on the window contents of any application connected to the X server. Under Wayland, the application (Firefox) talks directly to the window manager.
No, this is not helping. I’ve just installed gufw (to test this), but as @skynet already wrote this doesn’t execute it under Wayland on Debian10/PureOS.
~$ xhost +SI:localuser:root
localuser:root being added to access control list
~# gufw
Unable to init server: Could not connect: Connection refused
(gufw.py:3117): Gdk-CRITICAL **: etc.
/usr/bin/gufw-pkexec: line 13: 3117 Segmentation fault python3 ${LOCATIONS[${i}]} $1
Same like with synaptic, gufw works (tested it) only under System X11 Default/GNOME on Xorg:
Additional info: https://wayland.freedesktop.org/docs/html/ch05.html
So, by switching to root manually, and by setting xhost to allow root to access the server, you don’t need pkexec. Of course, given the rather terrible layout and badly written code in gufw, it’s no surprise that it tries to use pkexec even when $EUID is already 0… Anyway, once you switch to root, try running python3 /usr/share/gufw/gufw/gufw.py (or if that fails with a file not found error, use dpkg-query -L $gufw_package_name to find where that file is located).
Then, seriously, switch away from gufw anyway, looking at the project layout, it’s terribly written. I wouldn’t recommend using it for something as security critical as a firewall, at least without giving it a very close look.
thanks for the feedback, do you think I should just use firewall configuration instead? it seems I am not the only one with the issue running gufw, it appears to be an issue with debian 10/pureos? I do not consider myself an expert in troubleshooting issues with pureos, but I am confused on how I should proceed. I installed gdb, and once I am in the gdb command line, what is the argument I should use to get the stacktrace?
Once you are in gdb, r⏎ will run the program, and should crash. Then bt⏎ will give the backtrace. Of course, realizing that it’s trying to use pkexec, it’s pretty obvious what the problem is (pkexec is broken under Wayland).
As for firewall config, I don’t use a graphical frontend, but my firewall setup is pretty simple, so I don’t really have a strong suggestion there. I’m just seriously unimpressed with the gufw package (it has problems, at least one of which has security implications).
ah yes I see now that it’s broken under wayland, therefore it simply will not run? that being said, I am do not need to make it work, as I can configure it through the command line, as I did with my ubuntu server. I appreciate your feedback especially related to gufw package. I suppose getting it to work would cause more problems perhaps in other areas, so I won’t be attempting it.
That pretty much sums it up. To be clear, glfw itself is (probably) not broken under wayland, it just calls pkexec in its launcher (even when pkexec is not appropriate, such as when already running as root), and pkexec is broken under wayland.
As for the more general issue of “how do I run a graphical program as root under wayland?” For X11 applications, that’s answered above. You can also run wayland native applications (which is most things these days, anything qt or gtk3 anyway) by specifying the full path to the wayland socket. By default it’s $XDG_RUNTIME_DIR/$WAYLAND_DISPLAY (usually /run/user/$UID/wayland-0). Note that’s the XDG_RUNTIME_DIR of the wayland session owner, not of root. You can also allow other users to access the wayland display by using setfacl to allow access to the socket (useful for running a program from inside a sandbox as a different user or similar).
There also can exist compositor specific ways to run things as root, but so far I don’t think any compositor has implemented that. It has the distinct advantage of letting the compositor securely collect the user password, which pkexec cannot do under X11.
wow great explanation, I am currently absorbing it all lol. when you say run a graphical program under root, do you mean as the root user, or using the sudo command. and this issue with gufw, that is an issue with pkexec being broken, and I wonder what other graphical apps use this? in other words, if I run into this issue with another gui of some other app, I would need to add the user I am logged into as allowable users? (as you specified above a few posts)
Now that’s a good question. It’s generally considered a terrible idea to run a graphical shell (X session or Wayland) as root, so can can pretty much assume someone always means “run a graphical program as root, under a non-root display”. That said, when you run sudo $command, it runs the command as root, essentially the same as if you were otherwise logged in as root (there are some slight differences in what environment variables get passed through, but for simplicity, they’re essentially the same).
Synaptic package manager also uses pkexec to re-run itself as root if needed, and also fails under Wayland. Unlike gufw, it actually correctly checks if it’s running as root already, and correctly tries to connect the the $WAYLAND_DISPLAY before giving up (with an actually helpful error message (although not perfectly helpful, as the suggested answer is “don’t use Wayland”)). If you launch it with $WAYLAND_DISPLAY pointing to a wayland socket, Syanptic will happily fire up and run as root.
The lazy, kick-the-can-down-the-road, solution would be to configure sudo (/etc/sudoers) to pass the $WAYLAND_DISPLAY environment variable through to root. There are some security implications for doing that, but it’s probably fine on a single-user system. Note that most compositors and programs treat WAYLAND_DISPLAY=wayland-0 as WAYLAND_DISPLAY=$XDG_RUNTIME_DIR/wayland-0, so you’d need to expand the path at some point, as you don’t want to pass XDG_RUNTIME_DIR through to root via sudo.
ah yes ok now I understand. so other programs are using pkexec, like gufw, but simply correctly checking if it’s running as root already, while gufw is failing to. other than gufw, I haven’t ran into any issues, so this is a first for me. not that I will, but would adding the $WAYLAND_DISPLAY to /etc/sudoers correct the gufw issue, or is it bigger than that?
Correct. Things like synaptic will detect they are running under Wayland, and reflect that in the generated error message if they cannot connect to a display. Correctly setting WAYLAND_DISPLAY under sudo would not correct the gufw issue, as it will try using pkexec regardless.
from > https://firewalld.org/
Who is using it?
firewalld is used in the following Linux distributions as the default firewall management tool:
RHEL 7 and newer CentOS 7 and newer Fedora 18 and newer SUSE 15 and newer OpenSUSE 15 and newer Available for several other distributionsApplications and libraries which support firewalld as a firewall management tool include:
NetworkManager libvirt podman docker (iptables backend only) fail2ban
i’m content with it because it’s tightly integrated with NetworkManager
In the category of dynamic firewall rules, fail2ban is excellent. It’s permissive by default, allowing clients to connect from anywhere, but watches various log files (apache/nginx, sshd, dovecot, and so on) for invalid connection attempts and blacklists the originating IP for a configurable length of time.