When to use pkexec vs. gksu/gksudo?

Question

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?

Answer 1

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"
        "http://www.freedesktop.org/standards/PolicyKit/1/policyconfig.dtd">
       <policyconfig>

         <vendor>Examples for the PolicyKit Project</vendor>
         <vendor_url>http://hal.freedesktop.org/docs/PolicyKit/</vendor_url>

         <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>
           <icon_name>audio-x-generic</icon_name>
           <defaults>
             <allow_any>no</allow_any>
             <allow_inactive>no</allow_inactive>
             <allow_active>auth_self_keep</allow_active>
           </defaults>
           <annotate key="org.freedesktop.policykit.exec.path">/usr/bin/pk-example-frobnicate</annotate>
         </action>

       </policyconfig>

   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
   shown:

       [IMAGE][2]

           +----------------------------------------------------------+
           |                     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:

       [IMAGE][3]

           +----------------------------------------------------------+
           |                     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).

Answer 2

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?

Answer 3

I am not satisfied with the given answers. Most claims about the advatages of pkexec are completely ridiculous and so far i tend to agree with Kevin Chadwick.

I am going to show in this post, that most of the claimed advantages for pkexec are also implemented in sudo (some however are not).

Lets be about it:

Claim #1: 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.

Answer: So does sudo. 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.

Claim #2: You can't run graphical applications via pkexec without explicitly configuring it to do so.

Answer: 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.

Claim #3: simply write an action definition file like this ...

Answer: "simply" ... dude, srsly?

Claim #4: 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.

Answer: Plain wrong. 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.

Claim #5: The so-called 'policies` of PolicyKit can be used to set more advances settings. For example, whether the password should be remembered.

Answer: Again 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.

Claim #6: Note that pkexec does no validation of the ARGUMENTS passed to PROGRAM.

Answer: Sudo does btw. Just saying. (Admitted, you can easily mess up with this, and it is normally not done).

---

But here comes the part, that I find interesting about PK:

Claim #7: You can tweak a little how you want programs to be run via pkexec: icon, text to display, [...]

Answer: Yeah, 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.

Claim #8: By granting it specific permissions only with a special policy. For example, the software centre uses PolicyKit to install/remove software, and when you grant it permission, it can use that permissions to install or remove software, and nothing else than that [...]

Answer: Now, this would be very, very interesting. Only I have trouble believing, that this is actually the case. I have no idea what OS mechanism could be used for that in Linux. Is pk doing something with pgroups here? But how can this affect software installation? I think pk might be depending on a certain cooperation with the application for that. In this case this is not really a feature of policykit but of the app you run with it. 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. Or did you mean instead: The software center itself runs in plain user context, and performs installation/removal via pkexec helper programs? Most obviously it could do that with sudo as well.

---

I would like to restate the original question: What are the advantages of pkexec over sudo?