Skip to main content ↑ ↓
Topic solved
This topic has been marked as solved and requires no further attention.
Topic: [SOLVED] doas does not work for graphical applications (Read 1977 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

[SOLVED] doas does not work for graphical applications

If i try to run any graphical application the following error is reported:

Code: [Select]
Invalid MIT-MAGIC-COOKIE-1 keyWarning: This program is an suid-root program or is being run by the root user.
The full text of the error or warning message cannot be safely formatted
in this environment. You may get a more descriptive message by running the
program as a non-root user or by removing the suid bit on the executable.
xterm: Xt error: Can't open display: %s

I run artix from a base install, with a minimal desktop environment (lightdm openbbox tint2).
It seems that doas can't read the $DISPLAY variable.

Re: doas does not work for graphical applications

Reply #2 –
Quote
It seems that doas can't read the $DISPLAY variable.

By default it doesn't. It's explained in the manual:

Quote from: man doas
By default, a new environment is created.  The variables HOME, LOGNAME, PATH, SHELL, and USER and the umask(2) are set to values appropriate for the target user.  DOAS_USER is set to the name of the user executing doas.  The variables DISPLAY and TERM are inherited from the current environment.  This behavior may be modified by the config file.

Quote from: man doas.conf
     The rules have the following format:

           permit|deny [options] identity [as target] [cmd command [args ...]]

[...]

     options      Options are:

                  nopass   The user is not required to enter a password.

                  nolog    Do not log successful command execution to syslogd(8).

                  persist  After the user successfully authenticates, do not ask for a password again for some time.

                  keepenv  Environment variables other than those listed in doas(1) are retained when creating the environment for the new process.

                  setenv { [variable ...] [variable=value ...] }
                           Keep or set the space-separated specified variables.  Variables may also be removed with a leading ‘-’ or set using the latter syntax.  If the first character of value is a ‘$’ then the value to be set is taken from the existing environment variable of the indicated name.  This option is processed after the default environment has been created.
 

Re: doas does not work for graphical applications

Reply #3 –
thanks for the suggestion.

I solved using the keepenv option int /etc/doas.conf

Re: doas does not work for graphical applications

Reply #4 –
Just in case you haven't clicked the above link:
Quote
Warning: All of the following methods have security implications that users should be aware of. As put by Emmanuele Bassi, a GNOME developer: "there are no *real*, substantiated, technological reasons why anybody should run a GUI application as root. By running GUI applications as an admin user you are literally running millions of lines of code that have not been audited properly to run under elevated privileges; you are also running code that will touch files inside your $HOME and may change their ownership on the file system; connect, via IPC, to even more running code, etc. You are opening up a massive, gaping security hole [...]."[1]

Avoid running graphical applications as root if possible, see #Circumvent running graphical apps as root.
I'm curious, what program do you need to run as root? If it's xterm with a root shell, you should just run
Code: [Select]
$ xterm -e doas su
instead.

Re: doas does not work for graphical applications

Reply #5 –
Quote from: strajder – on
Just in case you haven't clicked the above link:I'm curious, what program do you need to run as root? If it's xterm with a root shell, you should just run
Code: [Select]
$ xterm -e doas su
instead.

Wouldn't just "su" be enough? This reminds of the "sudo su" thing which is pure evil from my young days.

Re: doas does not work for graphical applications

Reply #6 –
Quote from: SGOrava – on
Wouldn't just "su" be enough? This reminds of the "sudo su" thing which is pure evil from my young days.
If you have set up doas as permit :wheel or similar to not have to type in password, it makes a difference. Of course, if that is not the case or not desired, use
Code: [Select]
$ xterm -e su

Re: doas does not work for graphical applications

Reply #7 –
I understand all the risks associated to the use of X11 application with sudo.
For this and many other reasons i don't use gnome or kde or any other heavy DE.
But i'm not a programmer and the use of vim or emacs is not an option for me. So, to respond to the reason why i must run graphical apps whit doas or sudo, it is only to edit configuration file with a simple editor like mousepad.
In this specific case i'm testing doas only because i use octopi (before someone can object  that aur helpers are dangerous, i  use octopi and yay only to speed up aur mangement, i never update  the system with these tools). Octopi use doas as default privilege elevation utility with sudo as fallback, so i was testing doas trying to solve some probems i have with octopi opening conf files from GUI.

Re: doas does not work for graphical applications

Reply #8 –
Quote from: purpleleaf – on
But i'm not a programmer and the use of vim or emacs is not an option for me. So, to respond to the reason why i must run graphical apps whit doas or sudo, it is only to edit configuration file with a simple editor like mousepad.
Have you tried using nano? It is more similar to text editors for DOS or Windows, while being TUI.

Its older sibling, joe, is (was?) available from AUR or from https://joe-editor.sourceforge.io/.