1

I know there is a bunch of similar questions around but they are all about a X-Forewarding and SSH sessions.

I got this problem with a local user which is privileged for a specific script...

The Problem

Under ubuntu 16.04 I want a specific user guest to be able to run one specific script /usr/sbin/test.sh with root privileges (the script make some system settings and mounts for example).

Settings

I extend the /etc/sudoers file with the following line:

guest   ALL = NOPASSWD: /usr/sbin/test.sh

guest is not in the sudo group ! (<-- guess this is the problem)

The Script

For sake of simplicity:

#!/bin/bash

zenity --info --text="Testing Sudo X"

The runs fine if executed with sudo /usr/sbin/test.sh from a member of the sudo-group or if there are no dialogues to show (means: making text and operations in a terminal window works without problems).

If guest logs in (via greeter) and start a new gnome-terminal in unity to execute sudo /usr/sbin/test.sh it fails with the (hope german is ok) error:

No protocol specified
Failed to connect to Mir: Failed to connect to server socket: Datei oder Verzeichnis nicht gefunden
Unable to init server: Verbindung ist gescheitert: Verbindungsaufbau abgelehnt

(zenity:19225): Gtk-WARNING **: cannot open display: :0

I tried....

  • exporting the $DISPLAY variable before or in the test.sh
  • cp the .Xauthority from anothers /home/user/ to my guest
  • generate a xauth cookie with xauth add from a xauth list of another user
  • add Defaults env_keep += "DISPLAY" in /etc/sudoers (did a mistake here!!!)

Question / Conclusion

None of this worked. I suppose that debugging things on guest would generally not help because the command runs with sudo. So I need to find a way to give guest a permission for the $DISPLAY or .Xauthority of sudo just for this single command.

Michael P
  • 113
  • 1
  • 1
  • 6

2 Answers2

1

From Ubuntu 16.04 onward, the DISPLAY is no longer on :0. It is on a number which can vary depending on how many users are simultaneously logged in to the console.

To resolve the problem, you need to configure sudo to preserve the DISPLAY environment variable.

Add a configuration file to the /etc/sudoers.d directory, containing the following:

Defaults env_keep += "DISPLAY"

This will allow sudo to pass the DISPLAY environment variable to the program it runs, and those programs will then be able to connect to the correct DISPLAY.

Michael Hampton
  • 237,123
  • 42
  • 477
  • 940
  • I already tried this (sorry, I updated my question). I put this directly in the /etc/sudoers file after all other Defaults (e.g. Default = env_reset). Is this correct? Unfortunatly no change... – Michael P Apr 17 '19 at 15:06
  • @MichaelP Did you remove the bit where you manually set `DISPLAY`? – Michael Hampton Apr 17 '19 at 15:06
  • I tried it with and without `export`. And `echo $DISPLAY` gives `:0` but the user is not allowed to `sudo echo $DISPLAY`. `echo $XAUTHORITY` gives `/home/guest.Xauthority`...so everythings seems ok – Michael P Apr 17 '19 at 15:12
  • I suggest you log out and log back in. – Michael Hampton Apr 17 '19 at 15:16
  • ....of course. I am also working on this in a virtualbox so I am reverting changes from time to time to make sure that everything is fresh at the next try. – Michael P Apr 17 '19 at 15:19
  • You were right. Another script of mine was messing around in the `guest`s homefolder and delted/changed the `.Xauthority`. Changing the `Default` did the trick. So technically this is a duplicated question :) – Michael P Apr 17 '19 at 18:21
1

You need to install xhost

for arch:

sudo pacman -S xorg-xhost

and then run:

xhost +
yagmoth555
  • 16,300
  • 4
  • 26
  • 48
Ryuuzaki Uchiha
  • 11
  • 1