Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Firefox does not start with pkexec #1217

apt-ghetto opened this issue Aug 11, 2019 · 1 comment


Copy link

commented Aug 11, 2019

Describe the bug
pkexec (because of com.github.calamares.calamares.policy) changes the $DISPLAY and $XAUTHORITY environment variables and runs Calamares with elevated privileges. If you launch Firefox from Calamares, Firefox is started as root, but won't run, because the session is owned by a regular user (this is the desired behaviour).
It is never a good idea to run Firefox as root, especially on live-systems where Firefox is usually outdated.

To Reproduce
Steps to reproduce the behavior:

  1. Boot live-system (I have tried it with Lubuntu 19.10)
  2. Open a terminal and execute pkexec calamares
  3. On the welcome screen, click on "Lubuntu support"

Expected behavior
Firefox opens and is usable and is running only as root, if the whole session is running as root.

Screenshots and Logs

16:43:00 [0]: QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
Running Firefox as root in a regular user's session is not supported.  ($XAUTHORITY is /home/lubuntu/.Xauthority which is owned by lubuntu.)
Running Firefox as root in a regular user's session is not supported.  ($XAUTHORITY is /home/lubuntu/.Xauthority which is owned by lubuntu.)
Running Firefox as root in a regular user's session is not supported.  ($XAUTHORITY is /home/lubuntu/.Xauthority which is owned by lubuntu.)
/usr/bin/xdg-open: 870: /usr/bin/xdg-open: iceweasel: not found
/usr/bin/xdg-open: 870: /usr/bin/xdg-open: seamonkey: not found
/usr/bin/xdg-open: 870: /usr/bin/xdg-open: mozilla: not found
/usr/bin/xdg-open: 870: /usr/bin/xdg-open: epiphany: not found
/usr/bin/xdg-open: 870: /usr/bin/xdg-open: konqueror: not found
/usr/bin/xdg-open: 870: /usr/bin/xdg-open: chromium: not found
/usr/bin/xdg-open: 870: /usr/bin/xdg-open: chromium-browser: not found
/usr/bin/xdg-open: 870: /usr/bin/xdg-open: google-chrome: not found
/usr/bin/xdg-open: 870: /usr/bin/xdg-open: www-browser: not found
/usr/bin/xdg-open: 870: /usr/bin/xdg-open: links2: not found
/usr/bin/xdg-open: 870: /usr/bin/xdg-open: elinks: not found
/usr/bin/xdg-open: 870: /usr/bin/xdg-open: links: not found
/usr/bin/xdg-open: 870: /usr/bin/xdg-open: lynx: not found
/usr/bin/xdg-open: 870: /usr/bin/xdg-open: w3m: not found
xdg-open: no method available for opening ''

Additional context
In Lubuntu, we use

Exec=bash -c "export BROWSER='sudo -H -u lubuntu firefox'; sudo -E calamares"

to circumvent this limitation. Obviously we use sudo instead of pkexec. But we were evaluating to switch to pkexec. That is also why I discovered this behaviour.

Possible short-term solution
Run external processes such as Firefox only as user, who owns the X11 session. (The user might be also root, although this is discouraged.)

Possible long-term solution
Calamares (the GUI/client part) should be run only as regular user (or root, if the whole session is owned by root). Actions, which really need elevated privileges such as partitioning, should be run separately (as a system process).
For example (for illustrative purposes, I don't know, if there is a KDE equivalent), the gvfs admin backend allows to edit a file owned by root in an editor with regular privileges.
This long-term solution should then also work with Wayland.


This comment has been minimized.

Copy link

commented Aug 13, 2019

This is basically a duplicate of #1051 (webview causes errors because WebEngine doesn't like to be root) #747 (wayland fails to start, because it wants to be root) and #523 (accessibility of a Qt-app-running-as-root), rolled into one.

There's a long-term plan to make it possible to run Calamares as non-root, and KPMCore does pretty well in that regard but all the other bits of Calamares (especially the Python modules running random commands through os.system()) haven't been looked at in this regard. I'd recommend running Calamares as non-root from your installer medium and then filing issues (or better yet, PRs) for the issues you find then.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
2 participants
You can’t perform that action at this time.