There are two general ways to run applications graphically as root (or, more generally, as another user). Programs like gksu, gksudo, and kdesudo are graphical frontends for sudo. In contrast, pkexec is a graphical frontend for PolicyKit.

When manually running programs as root (or as another, non-root user), what are the advantages/disadvantages (if any) of using pkexec, compared to the more traditional method of using a sudo frontend?


3 Answers 3


PolicyKit is more configurable, though pkexec doesn't make use of this configurability. Also, pkexec show the user the full path of the program that will be started, to that the user is a bit more sure what will happen. The so-called 'policies` of PolicyKit can be used to set more advances settings. For example, whether the password should be remembered.

Something I got from the pkexec manual:

The environment that PROGRAM will run it, will be set to a minimal known and safe environment in order to avoid injecting code through LD_LIBRARY_PATH or similar mechanisms. In addition the PKEXEC_UID environment variable is set to the user id of the process invoking pkexec. As a result, pkexec will not allow you to run e.g. X11 applications as another user since the $DISPLAY environment variable is not set.

More information on policies or action definitions from the pkexec manual:

   To specify what kind of authorization is needed to execute the program
   /usr/bin/pk-example-frobnicate as another user, simply write an action
   definition file like this

       <?xml version="1.0" encoding="UTF-8"?>
       <!DOCTYPE policyconfig PUBLIC
        "-//freedesktop//DTD PolicyKit Policy Configuration 1.0//EN"

         <vendor>Examples for the PolicyKit Project</vendor>

         <action id="org.freedesktop.policykit.example.pkexec.run-frobnicate">
           <description>Run the PolicyKit example program Frobnicate</description>
           <description xml:lang="da">Kør PolicyKit eksemplet Frobnicate</description>
           <message>Authentication is required to run the PolicyKit example program Frobnicate</message>
           <message xml:lang="da">Autorisering er påkrævet for at afvikle PolicyKit eksemplet Frobnicate</message>
           <annotate key="org.freedesktop.policykit.exec.path">/usr/bin/pk-example-frobnicate</annotate>


   and drop it in the /usr/share/polkit-1/actions directory under a
   suitable name (e.g. matching the namespace of the action). Note that in
   addition to specifying the program, the authentication message,
   description, icon and defaults can be specified. For example, for the
   action defined above, the following authentication dialog will be


           |                     Authenticate                     [X] |
           |                                                          |
           |  [Icon]  Authentication is required to run the PolicyKit |
           |          example program Frobnicate                      |
           |                                                          |
           |          An application is attempting to perform an      |
           |          action that requires privileges. Authentication |
           |          is required to perform this action.             |
           |                                                          |
           |          Password: [__________________________________]  |
           |                                                          |
           | [V] Details:                                             |
           |  Command: /usr/bin/pk-example-frobnicate                 |
           |  Run As:  Super User (root)                              |
           |  Action:  org.fd.pk.example.pkexec.run-frobnicate        |
           |  Vendor:  Examples for the PolicyKit Project             |
           |                                                          |
           |                                  [Cancel] [Authenticate] |

   If the user is using the da_DK locale, the dialog looks like this:


           |                     Autorisering                     [X] |
           |                                                          |
           |  [Icon]  Autorisering er påkrævet for at afvikle         |
           |          PolicyKit eksemplet Frobnicate                  |
           |                                                          |
           |          Et program forsøger at udføre en handling der   |
           |          kræver privilegier. Autorisering er påkrævet.   |
           |                                                          |
           |          Kodeord: [___________________________________]  |
           |                                                          |
           | [V] Detaljer:                                            |
           |  Bruger:   Super User (root)                             |
           |  Program:  /usr/bin/pk-example-frobnicate                |
           |  Handling: org.fd.pk.example.pkexec.run-frobnicate       |
           |  Vendor:   Examples for the PolicyKit Project            |
           |                                                          |
           |                                [Annullér] [Autorisering] |

   Note that pkexec does no validation of the ARGUMENTS passed to PROGRAM.
   In the normal case (where administrator authentication is required
   every time pkexec is used), this is not a problem since if the user is
   an administrator he might as well just run pkexec bash to get root.

   However, if an action is used for which the user can retain
   authorization (or if the user is implicitly authorized), such as with
   pk-example-frobnicate above, this could be a security hole. Therefore,
   as a rule of thumb, programs for which the default required
   authorization is changed, should never implicitly trust user input
   (e.g. like any other well-written suid program).
  • 3
    I understand that PolicyKit is used to allow programs to perform only specific types of actions. But does pkexec facilitate that, or does pkexec just run things as root with unrestricted abilities? The pkexec manual excerpt you included in your answer documents how to write rules to determine who can run a program as root (or as another, non-root user), rather than what the program can do. Nov 12, 2011 at 19:16
  • 4
    I want to accept your answer, as it provides a lot of good information. But I feel that it's very misleading, because it says that pkexec is more configurable than sudo, and given the discussion we've had here in the comments, that does not seem to be the case. Would you consider editing your answer to either explicate sudo's configurability and compare/contrast it to pkexec's, or edit your answer to say that the difference is something other than configurability? Nov 15, 2011 at 17:52
  • 3
    "simply write" and then a chunk of XML. I needed that laugh. May 5, 2014 at 7:06
  • 2
    so making a pkexec alias as explained here askubuntu.com/a/332847/46437 will make is less safe? but will it still be more safe than gksudo? and instead of an alias, a script with root privileges could be safer? Jun 22, 2014 at 21:00
  • 2
    FYI pkexec can run GUI without configuration: askubuntu.com/a/332847/89385 Jan 14, 2016 at 8:50

With sudo you can set per user and per program policies about wether to retain or reset the callers environment in the context of sudo. The env_reset policy is set by default.

You can't run graphical applications via pkexec without explicitly configuring it to do so. Because this is merely a result of the environment reset this is obviously true for sudo as well. Note however thet neither pkexec nor sudo can prevent a malevolent application running as root to retrieve all neccessary information from the display managers or the users X11-cookie file. The latter, both or similiar, may even be done by non root applications depending on circumstances.

Sudo does not require explicit listings of users. Listing any user group or even setting a permission for all users in general can be done. The target_pw directive allows those users to authenticate with the credentials of the user in whoose context they want to run an application, i.e. root. Apart from that the equally traditional su (su / gtksu / kdesu) program can be used to do the very same without special configuration.

sudo, too, allows the user to remain authenticated for a specified time. The option is named timeout, configurable globally, per user, or per application. Authentication can be retained per tty or globally per user.

While pkexec may do no validation of the ARGUMENTS passed to PROGRAM, sudo does indeed have this feature. Admitted though, you can easily mess up with this, and it is normally not done.

You can tweak a little how you want programs to be run via pkexec: icon, text to display, you can even have localization stuff and all that. Depending on circumstances this can be nifty indeed. Sad though, that someone felt the need to reinvent the wheel for this feature. This would probably be something to put into the graphical gtksudo/kdesu wrappers.

Policykit is only a centralized configuration framework then. Unfortunately not a pretty one. PKs XML-Files are way more complicated than anything an app could provide natively short of binary files. And no one would be so looney to use binary ... oh gconf ... never mind.

  • 9
    I downvoted because this post isn't really an answer, it's a criticism of another answer. If you feel that it usually a better choice to use sudo over pkexec, say so, explaining your point with these rebuttals.
    – Flimm
    Jan 29, 2013 at 20:29
  • 4
    Thanks Paul, for lots of helpful analysis here! But I also agree with Flimm. Can you start off with a simple answer to the question as asked?
    – nealmcb
    Apr 24, 2013 at 15:08
  • 2
    No, pkexec can run GUI without configuring: askubuntu.com/a/332847/89385 Jan 14, 2016 at 8:50

A few things how pkexec is different from sudo and its frontends:

  1. You can't run graphical applications via pkexec without explicitly configuring it to do so.
  2. You can tweak a little how you want programs to be run via pkexec: icon, text to display, whether to remember the password or not, whether to allow it to run graphically and some more.
  3. Anybody can run "Run as" a superuser (provided they can authenticate as such), with sudo you have to be listed in the sudoers file as admin.
  4. gksudo locks the keyboard, mouse, and focus when asking for a password, pkexec doesn't. In both cases the keystrokes are sniffable though.
  5. With pkexec you work in a slightly more sanitized environment.

Try for example:

cd /etc/init.d
sudo cat README
# and now the same with pkexec
pkexec cat README
# nice, huh?
  • Good point (#3) about how you can authenticate as other users' to run programs as root with pkexec. Is it configurable, which users can use pkexec at all (even if they know the password of another user who is permitted to do so)? su is configurable in this way. When I attempt to su to another non-root user as guest on an Oneiric system, it tells me I am not permitted to do so. (In contrast, when I try to use pkexec as guest on Oneiric or Precise, I get what looks like an assertion error, which I may soon report as a bug, as I shouldn't get that even if it isn't allowed.) Nov 15, 2011 at 23:56
  • 2
    But sudo and its frontends can also be tweaked as described in point 2. You can run a program with gksu or gksudo displaying customized text, stop needing some users' passwords by editing /etc/sudoers (with visudo), and change how long they are remembered in the sense of changing how long it takes for sudo to time out (though I am not sure how to do this on Ubuntu, which is configured so that the questions of whether or not sudo needs a password, and how long until it will need one again, are terminal-specific). Nov 15, 2011 at 23:57
  • #4 is not true if you're using GNOME Shell.
    – muru
    Sep 25, 2014 at 14:16
  • 2
    No, pkexec can run GUI without configuring: askubuntu.com/a/332847/89385 Jan 14, 2016 at 8:49

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .