If my display path is anything other than 0.0 I also getĪuthorization required, but no authorization protocol specified QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-lw' qt.qpa.screen: QXcbConnection: running vcxsrv -ac from powershell (command not recognized).running vcxsrv -ac from bash (command not recognized).switching to another graphics application.However, once I upgraded to WSL2 (needed for docker) the graphic export stopped working. (gedit:2349): Gtk-WARNING **: cannot open display: :0īefore Wayland, running GUI applications with elevated privileges could be properly implemented by creating a Polkit policy, or more dangerously done by running the command in a terminal by prepending the command with sudo but under (X)Wayland this does not work anymore as the default has been made to only allow the user who started the X server to connect clients to it (see the bug report and the upstream commits it refers to).Īvoid running graphical applications as root if possible, see #Circumvent running graphical applications as root.Ī more versatile though more insecure workaround allows any graphical application to be run as root #Using xhost.I was able to use graphic applications in WSL using XMING and Export DISPLAY=:0.0 Unable to init server: Could not connect: Connection refused GParted or Gedit), will fail with an error similar to this: Trying to run a graphical application as root via su, sudo or pkexec in a Wayland session (e.g. Where appname is the name of the particular app. XAUTHORITY=/home/ username/.Xauthority appname This will permanently allow root to connect to a non-root user's X server. Then switch to your root user using su or su -.Įxport XAUTHORITY=/home/ username/.Xauthority Permanently allow root access Method 1: Add the line session optional pam_xauth.so Xhost can be used to temporarily allow root access. If you are behind a firewall, you may consider them to be safe enough for your requirements. These methods will allow root to connect to a non-root user's X server, but present varying levels of security risks, especially if you run ssh. sux AUR (wrapper around su which will transfer your X credentials).These methods wrap the application in an elevation framework and drop the acquired privileges once it exits: This may be the object of a bug report to the upstream project. Applications should rather " defer the privileged operations to an auditable, self-contained, minimal piece of code that gets executed after doing a privilege escalation, and gets dropped when not needed". This should however " only be used for legacy programs", as pkexec(1) reminds. The proper, recommended way to run GUI applications under X with elevated privileges is to create a Polkit policy, as shown in this forum post. There are multiple ways of allowing root to do so however, if necessary. Xorgīy default, and for security reasons, root will be unable to connect to a non-root user's X server. The same effect can be attained via the Other locations server address bar. in nautilus or gedit, type Ctrl+l and then prepend the admin:// scheme to the resource path. Tip: This can also be done from the application location bar/file selector: e.g.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |