[Wayland] Cannot launch BiT as root

[Philetjosie]

Hello,
I recently update to Ubuntu 17.10, under Gnome. I try to launch BiT from Gnome, but it does not work (nothing happen). From a terminal, launching backintime-qt4 works fine (Version: 1.1.24), but for my purpose I need root authorisation. When I launch in a terminal pkexec backintime-qt4 I get the following error code: «Invalid MIT-MAGIC-COOKIE-1 keyapp.py: cannot connect to X server :0».
BiT is essential for me, what can I do to overcome this problem ?
Best regards.

[Germar]

This is a problem with Wayland. Take a look at this Bug and the workaround:

xhost si:localuser:root

[Saroumane]

Hello, I'm using

• Backintime 1.2.1
• Ubuntu 20.10
• Gnome 3.38.

When I go back to X session, everything is fine.
But when I'm logged with Wayland, I can't start backintime GUI, not for the logged user, not for the root. (Fortunately backintime still works for backups when scheduled with crontab)

I tried every known workaround without success :

$ xhost si:localuser:root

$ xhost+

$ sudo -EH backintime

Each time backintime fails silently (for logged user or root)

I also compiled git master branch (Version: 1.2.0 git branch 'master' hash '7d24d1d' . That is < 1.2.1, is it normal ?) : same result.

[Saroumane]

I found my workaround :

$ sudo nano /usr/bin/backintime-qt_polkit

line 4 , replace :
PREFIX="env QT_QPA_PLATFORM=wayland-egl XDG_RUNTIME_DIR=$XDG_RUNTIME_DIR"

by

PREFIX="XDG_RUNTIME_DIR=$XDG_RUNTIME_DIR"

And now you can start backintime as usual with Activities / Application Menu.

[Saroumane]

Now Ubuntu 21.04 defaults to wayland session, but the workaround above does not work anymore for root.
So I reversed it and instead I edited directly the shortcut :

$ sudo nano /usr/share/applications/backintime-qt-root.desktop

then replace

Exec=/usr/bin/backintime-qt_polkit %f

with

Exec=/usr/bin/pkexec /usr/bin/backintime-qt

[aryoda]

@Saroumane THX for reporting your work-around here! I have assigned this issue to myself and will revisit it when I find the time to investigate all Wayland-related issus (I am currently trying to fix other most-pressing issues.)

Regarding your proposed work-around: I am wondering if directly executing BiT via pkexec in the .desktop file will still use Wayland or falls back to XWayland which would explain why BiT (root) starts again. This is no real problem except the usual X11 security issues (that naturally exist too if plain vanilla X11 is used) - Wayland was also designed to improve the security by separating the clients more consequently.

[aryoda]

I can reproduce the non-starting BiT-GUI as root on OpenSuse TumbleWeed with Wayland.

Trying the proposed work-around

 $ sudo nano /usr/bin/backintime-qt_polkit

line 4 , replace :
PREFIX="env QT_QPA_PLATFORM=wayland-egl XDG_RUNTIME_DIR=$XDG_RUNTIME_DIR"

did not work but in fact starting BiT with pkexec backintime-qt does work (using xcb = XWayland instead of native wayland).

I also tried xhost si:localuser:root but it did not work neither.

Perhaps the wayland security model is so strict now that wayland root GUIs are no longer working.

It could be related to #1592 since Qt5 is fully blocking...

[aryoda]

I think using the standard X11/xcb plugin of Qt5 is the way to solve this problem (instead of using wayland-egl:

• For BiT root on X11 as well as on BiT (normal user) on Wayland we start the GUI just with plain pkexec:

  backintime/qt/backintime-qt

  Line 31 in 1b9e3b3

  python3 -Es ${APP_PATH}/app.py "$@"

• BiT root already uses pkexec but also the Qt5 wayland-egl architecture plugin:

  backintime/qt/backintime-qt_polkit

  Lines 3 to 9 in 1b9e3b3

  	if [ "x$XDG_SESSION_TYPE" = "xwayland" ]; then
  	PREFIX="env QT_QPA_PLATFORM=wayland-egl XDG_RUNTIME_DIR=$XDG_RUNTIME_DIR"
  	else
  	PREFIX=""
  	fi
  	pkexec --disable-internal-agent $PREFIX "/usr/bin/backintime-qt" "$@"

  By default pkexec does not allow to run X11 applications as another user
  since the DISPLAY and XAUTHORITY environment variables are not set.
  Without these variables set no user (neither root nor unprivileged)
  can access X11 or XWayland.

  Solution: Explicitly set the variables for root to the values from the current user:

  pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY backintime-qt
  

  This is not required if a polkit policy file exists with the
  org.freedesktop.policykit.exec.allow_gui property set
  like we do for Back In Time:

  backintime/qt/net.launchpad.backintime.policy

  Line 20 in 1b9e3b3

  <annotate key="org.freedesktop.policykit.exec.allow_gui">true</annotate>

  See: https://www.freedesktop.org/software/polkit/docs/latest/pkexec.1.html

  pkexec will not by default allow you to run X11 applications as another user since the $DISPLAY and $XAUTHORITY environment variables are not set. These two variables will be retained if the org.freedesktop.policykit.exec.allow_gui annotation on an action is set to a nonempty value; this is discouraged, though, and should only be used for legacy programs.

So I will change the backintime-qt_polkit script from Wayland to X11 since it does not help but causes only problems.

Once we refactor BiT to fully support native Wayland we can change this again.

[aryoda]

The launcher of timeshift (referenced in the PR #1347) looks very sophisticated and contains one commit message explaining why pkexec is used instead of setting DISPLAY and XAUTHORITY:

- pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY ${app_command}
+ pkexec ${app_command}

Simplify launch via pkexec

• remove usage of env: when timeshift is being launched via pkexec, envs like
  DISPLAY and XAUTHORITY are inherited from the current envoronment
• when they are set explicitly via the binary /usr/bin/env, X server does not permit access,
  the old method of launching did not work on ROSA KDE 4:

  Could not connect to display

• when /usr/bin/env is launched, the graphical policykit agent dialog shows that /usr/bin/env is being
  launched and does not show TimeShift's icon

There is no reason to use env, I believe. This patch fixes launching on ROSA.

Since this is stable for 4 years now I will do the same for our GUI launcher.

The big challenges are

• our systray icon plugin: It is launched by another script that does not differentiate between user and root/pkexec and even from cron jobs
• root cron jobs do not have a valid DISPLAY and XAUTHORITY env var (= not set) so pkexec does not help here.
  Maybe we should give up showing a sytray icon for BiT root (unless DISPLAY and XAUTHORITY are already set eg. when called via the BiT root GUI that uses pkexec.
  This would mean: Root cron jobs will not trigger the systray icon anymore

[aryoda]

Closed with PR #1597