Running graphical applications as root with doas

For the longest of times in my history using Free Software, I had been using the sudo command to elevate my normal user's privileges . I had learned early in my experience that using root for everything was a "dangerous" venture and we should only use it sparingly to perform specific admin tasks like updating the system and changing configuration files system-wide, and sudo had been the go-to tool for that for a good ten years of my Linux time.

This all changed one day when I was reading the Alpine Linux release notes and found out that the project chose to move away from sudo for the more modern and simplified doas tool, originally developed for the OpenBSD operating system. At the time, my love for Alpine had already bloomed and I was very excited about this. I even wrote a brief guide about setting some of the sudo behavior in doas so the transition becomes smooth.

Recently, however, I was surprised by one peculiarity of doas that I had not seen before: you cannot, by default, run X11 (graphical) applications as root through it. That was quite a disappointment to me, and frankly I thought it was a bad limitation of the command (perhaps a sacrifice to allow for its simplicity?). I even thought about installing sudo again, temporarily, but I found a way to work around it that was surprisingly little documented in the web. In this post, I'll share this with you so you may know as well.

Why are you running GUI stuff as root? Isn't it dangerous?

First of all, the big objection: sudo and doas were meant for administrators performing administrative tasks that are almost completely reserved for the command-line. Why am I running a graphical application as root, then? Aren't there other better ways to do what I want through the shell?

The answer is probably yes - but the problem is: I don't know how. My specific case for this was to run GParted, a graphical disk management utility, because I wanted to resize existing partitions in one of my backup disks. Expert sysadmins will probably scoff at my move and be able to type the commands blindfolded, but I specifically just can't do it from the shell. It's just so much easier and intuitive to visually see how the partitions are laid out and how you can grow/shrink each of them. And GParted is the perfect tool for it.

My case might be sound very specifc, but there are a few other specific tools that require some sort of root access to function properly, and the GUI is just the right interface for it. I'm thinking WireShark, Synaptic or even the file manager if it helps you better visualize something than the shell. In short: yes, you shouldn't be using root with random Xorg applications, but no, just because you shouldn't do something, it doesn't meant that shouldn't be able to do it if you needed to.

The workaround for Xorg: xhost

I narrowed down the cause of the doas errors as being because the user environment, containing X11 authentication variables, was not being carried over to root to execute it. Thus, root almighty ironically didn't have permission to open a window in the Xorg server, despite authenticating correctly!

I found this snippet of doas.conf configuration in the Arch Wiki that should've bridged that gap:

permit setenv { XAUTHORITY LANG LC_ALL } :wheel # or your username instead of :wheel

This would carry on the most important variable of Xorg ($XAUTHORITY that points to your .Xauthority file in your home directory) and thus enable you to authenticate a-la sudo. Except that it didn't work for me. The errors just kept carrying through. So what was I to do?

Deep searching this led to a post in some Linux subreddit where the person had the same problem and the exact not-working configuration with doas. The suggestion that worked? Use xhost, the command that allows you to configure access to Xorg. Essentially, it seems that xhost maintains some access control list much like SELinux etc but only concerning the X server's session. Thus, you can temporarily "lift" all access controls to it by issuing as a normal user:

$ xhost +

And then anyone can run applications in the X session, including root via doas gparted. The problem is that this is opens a gaping hole in your computer, especially if you have multiple users or have X listening on the network. You definitely don't want that. So you can limit the attack surface by being a little specific about the request:

$ xhost +IS:localuser:your_username

This grants permission only to your user, and in a local scope (i.e. not via the network). And you can then bring the system back to the original state by issuing:

$ xhost - # go back to original ACL.

This will close any concerns, but you might forget to do that in the middle of the tasks you're doing. After all, who knows how much time you'll need to fix your admin tasks? This is why I took this made a tiny "wrapper" script that will automatically close the gap in the end. It's simple, and looks like this:

#!/bin/bash
#
# gksudo: Shorthand to run graphical applications as root via doas under X11.
#
# It doesn't really use gksudo-the-program for this, instead wraps `doas` with
# commands to temporarily lift the X11 permission issues as it gets executed.
# I'm not sure if this is insecure or not, but seems like an OK compromise.
#

if [ $# == 0 ]
then
    echo "USAGE: gksudo [PROGRAM] [ARGS]"
    echo "Runs graphical PROGRAM as root, using doas"
    exit 1
fi

# Allow root to run graphical applications
xhost +SI:localuser:root > /dev/null

# run the application
doas $@

# Return to default config
xhost - > /dev/null

I named it gksudo to honor a long gone, but useful wrapper that was used to elevate privileges in graphical applications in Ubuntu. It's no longer used, but the name stuck with me, and this is exact the same use-case as it.

Save this script somewhere in your $PATH, make it executable and run as gksudo command. You'll be prompted for your password via doas as a backend. Defaults are restored in the end to cover your security.

Security and other concerns

Is this perfect? Not sure. If anything, Xorg by design isn't the most secure thing in the end, but I still use it (and so do many others). Lifting another layer of security out of it shouldn't be too bad as long as its use is restricted and temporary.

By all means do read the two Arch Wiki pages I linked above, especially the one about xhost, and decide for yourself whether this hack is usable or not, and please let me know if you think this is an issue and I should fix it. Less permissions? Closing the xhost permissions as soon as the application is launched?

One last thing that I must add on this that might not be too obvious: I run Xorg as a normal user, not as root. Translation: instead of using a display manager, I just run startx from the console straight into my window manager. I'm not sure how this affects the usability of this hack for those who use a display manager, but this works for my case specifically. And besides, I've heard that running Xorg through a display manager is also not very secure.

Do you ever run graphical applications as root via doas in your system? How do you do it? Let me know on Mastodon!

This post is number #46 of my #100DaysToOffload project.

Last updated on 11/06/23