Xdummy cannot be used in Xenial

[Sergio Callegari]

Xdummy is used by several systems for remote display, such as xpra (http://xpra.org/).

Unfortunately, since Xenial, it is completely impossible to use Xdummy for anything like that, because of the way in which permissions are set up for running X servers. This results in a serious compromise on the possibility of running remote displays systems on ubuntu. In fact, the latter can only rely on Xvfb with a less than optimal experience.

Most important,
Trying to run Xdummy from a console session results in

/usr/lib/xorg/Xorg.wrap: Only console users are allowed to run the X server

It should be possible to start Xdummy from an ssh session. Xdummy is a 'dummy' display driver. It does not touch real hardware. There is no need to prevent users who are not on the console from starting it. In fact, it is not clear what is the purpose of taking the effort of packaging and shipping Xdummy at all, if it cannot be used for the tasks it is intended for.

See also:

http://xpra.org/trac/ticket/1220

The Xpra developer, whose availability to help is always excellent, explicitly states that:

- it is not possible to use xdummy with almost all Ubuntu releases [in fact the problem is Xenial. Before xenial, xdummy required some tweaks, but worked]

- xpra needs to be compiled with the --without-Xdummy on Ubuntu because of this

- There is nothing that can be done in xpra, because this is an OS permission problem

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: xserver-xorg-video-dummy 1:0.3.7-1build5
ProcVersionSignature: Ubuntu 4.4.0-22.40-generic 4.4.8
Uname: Linux 4.4.0-22-generic x86_64
ApportVersion: 2.20.1-0ubuntu2.1
Architecture: amd64
CurrentDesktop: KDE
Date: Mon Jun 6 11:54:50 2016
EcryptfsInUse: Yes
InstallationDate: Installed on 2013-12-12 (906 days ago)
InstallationMedia: Kubuntu 13.10 "Saucy Salamander" - Release amd64 (20131016.1)
SourcePackage: xserver-xorg-video-dummy
UpgradeStatus: Upgraded to xenial on 2016-04-21 (45 days ago)

[Sergio Callegari (callegar)]

After some investigation, the problem seems to be in the Xorg.wrap wrapper that is way too picky.

1) Without the wrapper Xdummy cannot be executed because it tries to open some virtual console and fails

2) With the wrapper Xdummy cannot be executed either because

a) you need to modify the Xwrapper.conf file to let anybody run it first
b) The wrapper protests that it cannot run with elevated privileges and options for Xorg including -logfile and -configdir, but these are obviously required if one wants to start Xdummy under the control of another application such as Xpra

To me, it is totally unclear why:

a) Xdummy should need to run with privilege at all otherwise Xorg messes with the virtual consoles.

b) The wrapper cannot have its own options making it more flexible and a group to manage it, so that only the users with appropriate permissions (in the appropriate group) can start the wrapper with the options relaxing its behavior (e.g. allowing -logfile and -confdir)

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[G Carl (h-lauc9pad-k)]

I've gotten Xpra to work with Xdummy on lubuntu 16.04 by by starting Xpra on a virtual console. This may not support your use case but it works for mine.

INSTALLATION
sudo apt-get install xpra
apt list xpra
  xpra/xenial,now 0.15.8+dfsg-1 amd64 [installed]
sudo usermod -aG tty <USERNAME>

USE FROM DESKTOP
Workaround for 16.04 issues. Start xpra on a /dev/tty
ll /dev/tty63
  crw-r----- 1 root tty 4, 63 Jul 15 17:34 /dev/tty63
#group needs rw access to openvt tty
sudo chmod 660 /dev/tty63
ll /dev/tty63
  crw-rw---- 1 root tty 4, 63 Jul 15 17:34 /dev/tty63
openvt -c 63 -f -- xpra start :80 --daemon=no

START WITH BOOT
[Unit]
Description=Xpra server

[Service]
Type=simple
Environment=TTYNum=63 DISPLAY=:90

#openvt will execute as root so requires no permission change on /dev/tty##
#then sudo to user running xpra
ExecStart=/bin/openvt -c $TTYNum -f -v -w -- /usr/bin/sudo --user <USERNAME> --login /usr/bin/xpra start $DISPLAY --daemon=no

ExecStop=/usr/bin/sudo --user <USERNAME> --login /usr/bin/xpra stop $DISPLAY

[Install]
WantedBy=graphical.target

[Seth (bugs-sehe)]

@G Carl (h-lauc9pad-k) thanks for that. The openvt trick looks very promising.

I've created the systemd service and the server appears to start/stop like a charm.

However, attempts to run X clients on the xpra server still result in

/usr/lib/xorg/Xorg.wrap: Only console users are allowed to run the X server
xauth: timeout in locking authority file /home/sehe/.Xauthority
Error running "xauth add :90 MIT-MAGIC-COOKIE-1 34681eca98b041fcadf12b5398bc0f4e": non-zero exit code: 1
2016-10-31 00:27:31,096
2016-10-31 00:27:31,096 Xvfb command has terminated! xpra cannot continue
2016-10-31 00:27:31,096

Does the `Xauthority` stuff indicate something else still, or is important at all?

[Seth (bugs-sehe)]

Fixed that Xauthority stuff. It was caused by me having `ForwardX11 yes` in `.ssh/config` for that host. Now I still get the following in /home/sehe/.xpra/:90.log:

/usr/lib/xorg/Xorg.wrap: Only console users are allowed to run the X server
2016-10-31 00:45:25,027
2016-10-31 00:45:25,027 Xvfb command has terminated! xpra cannot continue
2016-10-31 00:45:25,027

[G Carl (h-lauc9pad-k)]

Do you have a set of parent/child processes like this? Note the middle 2 are running on tty63.

ps -f 748 750 926 1089
UID PID PPID C STIME TTY STAT TIME CMD
root 748 1 0 20:45 ? Ss 0:00 /bin/openvt -c 63 -f -v -w -- /usr/bin/sudo --user user --login /usr/bin/xpra start :90 --daemon=no
root 750 748 0 20:45 tty63 Ss+ 0:00 /usr/bin/sudo --user user --login /usr/bin/xpra start :90 --daemon=no
user 926 750 0 20:45 tty63 Sl+ 0:00 /usr/bin/python /usr/bin/xpra start :90 --daemon=no
user 1089 926 0 20:45 ? Ssl 0:01 /usr/lib/xorg/Xorg -noreset -nolisten tcp +extension GLX +extension RANDR +extension RENDER -auth /home/user

[Bharat Kunwar (brtkwr)]

I have documented how I resolved this issue on my blog:
http://brtknr.com/2017/03/15/permission-issues-with-xpra-on-ubuntu-16-04-when-tunnelling-through-SSH/

Turns out that the version of xpra (0.15.x) provided with Ubuntu 16.04 is not supported anymore and updating to 2.0.x resolved the issue.