[SOLVED] Running qt apps with Doas segment faults (Solution at bottom)

Samus · 2024-05-31 19:30:35

I use Doas in place of Sudo, and it works for the most part. However, when I go to run qt applications with doas (such as dolphin, dolphin-emu, randovania, etc), I get this error:

Authorization required, but no authorization protocol specified

qt.qpa.xcb: could not connect to display :0
qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, wayland-egl, wayland, wayland-xcomposite-egl, wayland-xcomposite-glx, xcb.

Aborted (core dumped)

I tested this on a hello world. The source code is as follows:

#include <QApplication>
#include <QLabel>

int main(int argc, char **argv)
{
    QApplication app(argc, argv);
    QLabel hello("Hello world!");

    hello.show();
    return app.exec();
}

Ran via

doas ./hello

The backtrace I get from this is as followed:

Thread 1 "hello" received signal SIGABRT, Aborted.

0x00007ffff64a8e44 in ?? () from /usr/lib/libc.so.6

(gdb) bt full

#0  0x00007ffff64a8e44 in ?? () from /usr/lib/libc.so.6

No symbol table info available.

#1  0x00007ffff6450a30 in raise () from /usr/lib/libc.so.6

No symbol table info available.

#2  0x00007ffff64384c3 in abort () from /usr/lib/libc.so.6

No symbol table info available.

#3  0x00007ffff6a98143 in QMessageLogger::fatal(char const*, ...) const () from /usr/lib/libQt5Core.so.5

No symbol table info available.

#4  0x00007ffff7132d77 in QGuiApplicationPrivate::createPlatformIntegration() () from /usr/lib/libQt5Gui.so.5

No symbol table info available.

#5  0x00007ffff7133421 in QGuiApplicationPrivate::createEventDispatcher() () from /usr/lib/libQt5Gui.so.5

No symbol table info available.

#6  0x00007ffff6cb327d in QCoreApplicationPrivate::init() () from /usr/lib/libQt5Core.so.5

No symbol table info available.

#7  0x00007ffff71334d7 in QGuiApplicationPrivate::init() () from /usr/lib/libQt5Gui.so.5

No symbol table info available.

#8  0x00007ffff7953586 in QApplicationPrivate::init() () from /usr/lib/libQt5Widgets.so.5

No symbol table info available.

#9  0x0000000100001211 in main ()

No symbol table info available.

(gdb) c

Continuing.

Couldn't get registers: No such process.

(gdb) [Thread 0x7ffff34006c0 (LWP 162971) exited]

What can I do to fix these applications segfaulting when being ran via doas?
For reference, this is the content of /etc/doas.conf:

permit samus
permit nopass samus cmd pacman
permit nopass samus cmd flatpak
permit nopass samus cmd reboot
permit nopass samus cmd poweroff
#permit persist :samus
deny samus cmd vim args /etc/doas.conf
deny samus cmd vim args /etc/sudoers
deny samus cmd vim args /etc/samba/smb.conf
deny samus cmd vim args /etc/crypttab
deny samus cmd vim args <passkey-location>
deny samus cmd vim args /etc/apparmor.d/local/usr.sbin.smbd
deny samus cmd vim args /etc/apparmor.d/local/abstractions/libvirt-qemu
deny samus cmd visudo
deny samus cmd su
deny samus cmd rm
deny samus cmd pacman args sudo
deny samus cmd pacman args doas

[Other Info]:

Operating System: Arch Linux
KDE Plasma Version: 6.0.5
KDE Frameworks Version: 6.2.0
Qt Version: 6.7.1
Kernel Version: 6.9.1-hardened1-2-hardened (64-bit)
Graphics Platform: X11
Processors: 24 × AMD Ryzen 9 5900X 12-Core Processor
Memory: 62.7 GiB of RAM
Graphics Processor: AMD Radeon RX 6900 XT

[Solution]:

Add this line within /etc/doas.conf:

permit setenv { XAUTHORITY LANG LC_ALL } :username

Important Note: Replace "username" with your actual username.
(that is at least what I did, that worked. The wiki for doas mentions using :wheel, but that did not work in my case.)

Last edited by Samus (2024-06-01 00:52:39)

gromit · 2024-05-31 19:37:28

Note that the backtrace is useless without, debug symbols ... Please activate debuginfod at the beginning of the gdb session

https://wiki.archlinux.org/title/Debugg … ing_traces

arojas · 2024-05-31 20:33:41

The backtrace is useless anyway, with or without debug symbols, as this is an abort and the meaningful info is in the stdout message.

The root user can't connect to your X session unless you explicitly pass the xauth token.

seth · 2024-05-31 21:59:23

Dolphin even used to have an explicit "don't do stupid stuff, I'm not gonna run as root" abort regardless of proper environment and also that's not necessary

NepJr · 2024-05-31 23:07:58

permit setenv { XAUTHORITY LANG LC_ALL } :wheel

Put this in your doas.conf

Samus · 2024-06-01 00:41:39

arojas wrote:

The backtrace is useless anyway, with or without debug symbols, as this is an abort and the meaningful info is in the stdout message.
The root user can't connect to your X session unless you explicitly pass the xauth token.

NepJr wrote:

permit setenv { XAUTHORITY LANG LC_ALL } :wheel
Put this in your doas.conf

This worked, albeit with the change :wheel becoming :username (my actual username, not "username").
Thank you for your assistance - it would appear as though this line is necessary to run some applications as root via doas.
Marking this as solved after editing the solution into the initial post

Thank you all for your help

Last edited by Samus (2024-06-01 00:55:28)

seth · 2024-06-01 06:12:34

https://man.archlinux.org/man/extra/ope … .conf.5.en - see what the color actually does and what :wheel therefore implied and what :username not means.

Then take a step back: running a fat GUI client as root - sudo, doas, nomatter, is a bad idea and i 99% of all cases where you *think* you want/have to do this, you actually didn't.
The question you need to ask isn't "ok, how do I make this run as root", but "ok, where did I fuck up to arrive at this point".

Running filemanagers or editors as root is typically NOT necesary.
As pointed out, dolphin won't allow you to run it as root anyway but instead ask for permissions to operate on privileged paths and for the most common case of "but how do I edit my fstab", the answer is "sudoedit", in case of doas, there's some bash scripts that do the same (https://aur.archlinux.org/packages?O=0&K=doasedit - results unvetted, if it's more than a 100LOC bash script, it's probably not good)
For pretty much everything* else: why would you run that as root itfp?

*maybe gparted aside, though people running partitioning tools online, ie on a mounted drive, frequently show up because "helps, I repartitioned my disk and not the systemd doesn nots boots!!!", so use the gparted live distro.

Samus · 2024-06-01 12:09:35

I should probably say, I do not usually run Dolphin as root, that was solely for testing purposes

Arch Linux

#1 2024-05-31 19:30:35

[SOLVED] Running qt apps with Doas segment faults (Solution at bottom)

[Solution]:

#2 2024-05-31 19:37:28

Re: [SOLVED] Running qt apps with Doas segment faults (Solution at bottom)

#3 2024-05-31 20:33:41

Re: [SOLVED] Running qt apps with Doas segment faults (Solution at bottom)

#4 2024-05-31 21:59:23

Re: [SOLVED] Running qt apps with Doas segment faults (Solution at bottom)

#5 2024-05-31 23:07:58

Re: [SOLVED] Running qt apps with Doas segment faults (Solution at bottom)

#6 2024-06-01 00:41:39

Re: [SOLVED] Running qt apps with Doas segment faults (Solution at bottom)

#7 2024-06-01 06:12:34

Re: [SOLVED] Running qt apps with Doas segment faults (Solution at bottom)

#8 2024-06-01 12:09:35

Re: [SOLVED] Running qt apps with Doas segment faults (Solution at bottom)

Board footer