Take the 2-minute tour ×
Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free, no registration required.

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?

share|improve this question
1  
    
Related: askubuntu.com/questions/252962/… –  Mechanical snail Apr 30 '13 at 4:50
add comment

3 Answers

up vote 14 down vote accepted

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).
share|improve this answer
1  
I guess I should have said there are two to run applications as root with graphical authentication. I had assumed there was a way to use pkexec to run graphical applications (I had just never done so...). Your answer explains why there is not (or at least why a custom environment has to be specified, to do it). –  Eliah Kagan Nov 12 '11 at 17:13
    
I do have one question about your answer, though--when a program is run as root with pkexec, in what sense can it capabilities ("permissions") be constrained? I grant a program the ability to do anything when I run it with sudo or a sudo frontend...in what sense does running a program as root with pkexec not also do this? –  Eliah Kagan Nov 12 '11 at 17:14
    
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. –  RobinJ Nov 12 '11 at 17:47
1  
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. –  Eliah Kagan Nov 12 '11 at 19:16
2  
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? –  Eliah Kagan Nov 15 '11 at 17:52
show 6 more comments

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?
share|improve this answer
    
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.) –  Eliah Kagan Nov 15 '11 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). –  Eliah Kagan Nov 15 '11 at 23:57
add comment

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.

Sudo and pkexec does no validation of the ARGUMENTS passed to PROGRAM. (Admitted, 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.

share|improve this answer
6  
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 '13 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 '13 at 15:08
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.