In Ubuntu 19.10 and later, the admonition in that article (and in this answer) no longer applies. See WinEunuuchs2Unix's answer as well as this question.
Graphical applications often store settings and other user-specific data in configuration files written inside the user's home folder. The main mechanism applications use to determine what they should use as the user's home folder is the HOME
environment variable. (You can inspect it yourself with echo $HOME
).
Suppose you're running gedit
(a graphical text editor) as root
. If you run sudo gedit
, HOME
will continue to point toward your home directory, even though the program is running as root
. Consequently, gedit
will write configuration files as root
into your home directory. This will sometimes result in the configuration files being owned by root
and thus inaccessible to you (when you later run the program as yourself and not as root
). This mainly happens when the application has to create a new configuration file. Newly created files, by default, are owned by the user who creates them (who in this case is root
, not you).
That's the primary reason why you should run graphical applications with a graphical sudo
frontend rather than with straight sudo
. In Ubuntu and most of its derivatives (including Xubuntu and Lubuntu), the standard graphical frontend is gksu
/gksudo
. In Kubuntu it is kdesudo
. (It depends on the desktop environment being used.)
If you want to use sudo
directly to run a graphical application like gedit
, you can run:
sudo -H gedit
The -H
flag makes sudo
set HOME
to point to root
's home folder (which is /root
).
That still won't automatically handle the ownership of .Xauthority
by copying it to a temp folder (this is the other thing that graphical sudo
frontends take care of for you). But in the infrequent event that .Xauthority
is inaccessible, you'll get an error saying it is, and then you can fix the problem by deleting it (sudo rm ~/.Xauthority
), as it's automatically regenerated. Thus, protecting .Xauthority
's ownership and permissions is less important than protecting the ownership and permissions of configuration files.
In contrast to a root
-owned .Xauthority
, when configuration files become owned as root
, it's not always as obvious what the problem is (because graphical programs will often run, but not work very well, and output any useful errors to the console). And it's sometimes a bigger hassle to fix, especially if you're in a situation where you want one or more files in your home directory to be owned by someone other than you (because then you cannot fix it simply by recursively chown
ing all your files back to yourself).
Therefore, sudo
(at least without -H
) should not be used to run a graphical application unless you are highly familiar with the app's inner workings and know for sure that it does not ever attempt to write any configuration files.
How to configure pkexec
to avoid getting errors when run GUI applications?
I found two possible ways:
As you can see, using the following:
pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY gedit
will not get you any error. And this is normal because man pkexec
is very clear in this matter:
[...] pkexec will not allow you to run X11 applications
as another user since the $DISPLAY and $XAUTHORITY environment
variables are not set.[...]
As result you can create an (permanent) alias (this is the simpliest way):
alias pkexec='pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY'
Or, (again) as man pkexec
says:
[...] 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.[...]
you can create a new policy file in /usr/share/polkit-1/actions
named com.ubuntu.pkexec.gedit.policy
with the following xml code inside where the most important thing is to set org.freedesktop.policykit.exec.allow_gui
to a nonempty value:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE policyconfig PUBLIC
"-//freedesktop//DTD PolicyKit Policy Configuration 1.0//EN"
"http://www.freedesktop.org/standards/PolicyKit/1/policyconfig.dtd">
<policyconfig>
<action id="com.ubuntu.pkexec.gedit">
<message gettext-domain="gparted">Authentication is required to run gedit</message>
<icon_name>gedit</icon_name>
<defaults>
<allow_any>auth_admin</allow_any>
<allow_inactive>auth_admin</allow_inactive>
<allow_active>auth_admin</allow_active>
</defaults>
<annotate key="org.freedesktop.policykit.exec.path">/usr/bin/gedit</annotate>
<annotate key="org.freedesktop.policykit.exec.allow_gui">true</annotate>
</action>
</policyconfig>
How to tell it to not ask for a password after the first time applying it to a command?
For these three setting tags: allow_any
, allow_inactive
and allow_active
from the policy file, the following options are available:
- no: The user is not authorized to carry out the action. There is therefore no need for authentication.
- yes: The user is authorized to carry out the action without any authentication.
- auth_self: Authentication is required but the user need not be an administrative user.
- auth_admin: Authentication as an administrative user is require.
- auth_self_keep: The same as auth_self but, like
sudo
, the authorization lasts a few minutes.
- auth_admin_keep: The same as auth_admin but, like
sudo
, the authorization lasts a few minutes.
Source: Polkit - Structure - Actions
So, if you use auth_admin_keep option (or, as applicable, auth_self_keep), pkexec
will not ask for a password again for some time (by default this time is set to 5 minutes as I checked). The disadvantage here is that this thing is applicable only for one - the same - command / application and valid for all users (unless if it is overruled in later configuration).
Where to save the configuration file if not yet existing?
Configuration files or polkit definitions can be divided into two kinds:
Actions are defined in XML .policy files located in /usr/share/polkit-1/actions
. Each action has a set of default permissions attached to it (e.g. you need to identify as an administrator to use the GParted action). The defaults can be overruled but editing the actions files is NOT the correct way. The name of this policy file should have this format:
com.ubuntu.pkexec.app_name.policy
Authorization rules are defined in JavaScript .rules files. They are found in two places: 3rd party packages can use /usr/share/polkit-1/rules.d
(though few if any do) and /etc/polkit-1/rules.d
is for local configuration. The .rules files designate a subset of users, refer to one (or more) of the actions specified in the actions files and determine with what restrictions these actions can be taken by that/those user(s). As an example, a rules file could overrule the default requirement for all users to authenticate as an admin when using GParted, determining that some specific user doesn't need to. Or isn't allowed to use GParted at all.
Source: Polkit - Structure
Is there a GUI application to configure pkexec
usage?
From what I know, until now (18.01.2014) doesn't exist something like this. If in the future I will find something, I will not forget to update this answer too.
Best Answer
The basic use is the same - the programs in question allow you to run other programs as another user, usually root. The difference, however, between
sudo
variants andpkexec
is thatsudo
gives a program total control over everything, while withpkexec
you have a much more fine grained control by defining a policy for each program.If you trust the programs that you run, sudo is perfectly fine. If you want to really lock down everything and permit programs to do only what you allow them to, then use
pkexec
that comes along with polkit.While the idea behind
pkexec
is nice, I wouldn't go as far as calling it the nextgksu
, due to the complex set up needed.Reference: the difference between sudo and pkexec on Quora.