X11: Run a Gnome App as Another User

X11: run a gnome app as another user

Use

xdg-su -u user -c command

X11: get list of all gnome-terminal windows on my display?

This option will run the new terminal window in its own process and as a distinct X client.

--disable-factory

These options

--instance=foo --class=bar

provide a convenient hook to distinguish between sessions:

$ xlsclients -l
...
Window 0x3000001:
  Machine:  ohm
  Name:  Terminal
  Icon Name:  foo
  Command:  foo
  Instance/Class:  foo/bar

How to set up working X11 forwarding on WSL2

TL;DR:

Add the following to your ~/.bashrc:

export DISPLAY=$(ip route list default | awk '{print $3}'):0
export LIBGL_ALWAYS_INDIRECT=1

Enable Public Access on your X11 server for Windows.*

Add a separate inbound rule for TCP port 6000 to the windows firewall in order to allow WSL access to the X server, as described by the wsl-windows-toolbar-launcher people.

---

As pointed out by WSL_subreddit_mod on reddit and as you can read in Microsoft's documentation on WSL2, the WSL2 architecture uses virtualized network components. This means that WSL2 has a different IP address than the host machine.
This explains why the X11 forwarding settings of WSL1 cannot simply be transferred to WSL2.

On the Ubuntu Wiki page about WSL you can already find a configuration adapted for WSL2 under Running Graphical Applications. A similar configuration is also suggested by the above mentioned Reddit User, who also contributes another part of the solution: Enable Public Access on the X11 server under Windows.

This means add the following to your ~/.bashrc:

export DISPLAY=$(ip route list default | awk '{print $3}'):0
export LIBGL_ALWAYS_INDIRECT=1

And Enable Public Access on your X11 server for Windows.*

The most important part to enable X11 forwarding for WSL2 on Windows 10 is still missing: the Windows firewall blocks connections via the network interface configured for WSL by default.

A separate inbound rule for TCP port 6000 is required to allow WSL access to the X server. After the rule has been created, as described by the wsl-windows-toolbar-launcher people, the IP address range can be restricted to the WSL subnet in the settings of the newly created rule, under Scope: 172.16.0.0/12.

*: If you use VcXSrv you can enable public access for your X server by disabling Access Control on the Extra Settings:



Or by calling vcxsrv.exe directly with the ac flag: vcxsrv.exe -ac as pointed out by ameeno on the github issue.

Alternatively this SO answer shows how to share keys via .Xauthority files, leaving you with intact access control.

X11 forwarding of a GUI app running in docker

Ok, here is the thing:

1) Log in to remote machine

2) Check which display was set with echo $DISPLAY

3) Run xauth list

4) Copy the line corresponding to your DISPLAY

5) Enter your docker container

6) xauth add <the line you copied>*

7) Set DISPLAY with export DISPLAY=<ip-to-host>:<no-of-display>

*so far so good right?

This was nothing new...however here is the twist:
The line printed by xauth list for the login user looks something like this (in my case):

<hostname-of-machine>/unix:<no-of-display> MIT-MAGIC-COOKIE-1 <some number here>

Because i use the bridged docker setup, the X forwarding port is not listening locally, because the sshd is not running in the container. Change the line above to:

<ip-of-host>:<no-of-display> MIT-MAGIC-COOKIE-1 <some number here>

In essence: Remove the /unix part.

<ip-of-host> is the IP address where the sshd is running.

Set the DISPLAY variable as above.

So the error was that the DISPLAY name in the environment variable was not the "same" as the entry in the xauth list / .Xauthority file and the client could therefor not authenticate properly.

I switched back to an untrusted X11 forwarding setting.

The X11UseLocalhost no setting in the sshd_config file however is important, because the incomming connection will come from a "different" machine (the docker container).

Access aliases in Gnome Run Application dialog

http://www.freedesktop.org/wiki/Specifications is probably a good place to start. I find these quite hard to follow most of the time, but sometimes you can figure it out. Specifically, the "Desktop Entry Specification".

Also, I don't think you'll be able to use any aliases from .bashrc, at least not without writing some kind of wrapper script. I think it needs to be an executable file. Of course, you could just use the good old symlinks- to- same + what's- my- name trick...

(Which, for reference, goes like this:

1. Make a script which uses its own name as a parameter.
2. Make symlinks to said script using the parameter values as the link names.)

---

Investigating...

Some casual investigation reveals that creating these is fairly simple if you use Nautilus, (at least the version I have):

1. Bring up the context menu for some random file, and use "Open With"->"Open with Other Application".
2. Unfold the "Use a custom command" and type in something like:
   
   
   1. xterm -e 'bash -c "unzip -l %f; sleep 5"'
3. This results in
   
   
   1. the command being run (so don't type rm -rf)
   2. a file in ~/.local/share/applications/ called xterm-usercreated.desktop

Here at least, I get the follow file:

[Desktop Entry]
Encoding=UTF-8
Name=xterm
MimeType=application/zip;
Exec=xterm -e 'bash -c "unzip -l %f; sleep 5"' %f
Type=Application
Terminal=false
NoDisplay=true

4: Looking at the system xterm .desktop I find this:

[Desktop Entry]
Type=Application
Encoding=UTF-8
Name=XTerm
GenericName=
Comment=XTerm: terminal emulator for X
Icon=/usr/share/pixmaps/xterm-color_32x32.xpm
Exec=xterm
Terminal=false
Categories=X-Debian-Applications-Terminal-Emulators;

5: Editing the .usercreated.desktop file to this:

[Desktop Entry]                                                                 
Type=Application                                                                
Encoding=UTF-8                                                                  
Name=xtermz                                                                     
Exec=xterm -e 'bash -c "unzip -l %f; sleep 5"' %f                               
Terminal=false                                                                  
Categories=X-Local-WTF                                                          

6: Run xdg-desktop-menu forceupdate --mode user

7: "xtermz" now shows up in the list... Success!

8: Yuck! This also makes it appear in the main menu, under "Other". Weird!

---

Some notes:

• In my Debian/testing, xdg-desktop-menu and friends (notably xdg-icon-resource) live in the xdg-utils package.
• You should be able to create a .desktop file from scratch.
• You should be able to install the .desktop file using xdg-desktop-menu install blah blah

Authenticating GTK app to run with root permissions

The old way, simple but now being phased out, is GKSu. Here is the discussion on GKSu's future.

The new way is to use PolicyKit. I'm not quite sure how this works but I think you need to launch your app using the pkexec command.

UPDATE:

Looking at the example code on http://hal.freedesktop.org/docs/polkit/polkit-apps.html, it seems that you can use PolicyKit to obtain authorization for certain actions which are described by .policy files in /usr/share/polkit-1/actions. The action for executing a program as another user is org.freedesktop.policykit.exec. I can't seem to find an action for directly accessing block devices, but I have to admit, the PolicyKit documentation breaks my brain too.

So, perhaps the simplest course of action for you is to separate your disk-mangling code that requires privileges into a command-line utility, and run that from your GUI application using g_spawn_[a]sync() with pkexec. That way you wouldn't have to bother with requesting actions and that sort of thing. It's probably bad practice anyway to run your whole GUI application as root.

Another suggestion is to ask the author of PolicyKit (David Zeuthen) directly. Or try posting your question to the gtk-app-devel list.

---

Related Topics