46

I defined 2 user accounts:

  • one with admin privilege (with sudo right) => lets call it adminuser.
  • a 2nd one without any privilege => lets call it normaluser
    and I configure the autologin on this 2nd user normaluser.

So when I open a normaluser session and want to run an application with admin privilege,
I open a terminal Ctrl+Alt+T and: 

su adminuser
sudo anyapplication ...

It works fine, without having to quit the normaluser session (no need to open a adminuser session).

But what should I do if the application needs to run with a GUI (Graphic User Interface) ?
I though about that:

su adminuser
gksu anyapplication ...

but I get

** (gksu:9122): WARNING **: the connexion is closed
No protocol specified
No protocol specified
(gksu:9122): Gtk-WARNING **: cannot open display: :0.0
Boris
  • 4,932
  • So the question is: why did you configure your system this way? Do you think it improves security? It is not :) Instead, you could've configured auto-login on your "admin" account so it won't ask you for password when you log in - it will still require a password when you perform administrative tasks. – Sergey Jul 17 '12 at 21:00
  • 7
    @Sergey If normaluser is sometimes used by someone who shouldn't be able to run commands as root, then making normaluser a non-administrator definitely improves security. The perils of giving someone a user account but not letting them know their own password go far beyond Boris's situation in hassle and complexity. If you want a full explanation of why that is problematic, I suggest posting a new question, but 3 of the reasons are that a user should be able to lock and unlock the screen, log out and back in with a different session type, and decrypt ecryptfs data. – Eliah Kagan Jul 17 '12 at 21:05
  • 2
    exactly, for me it makes no sense to use my family's PC letting everybody know the admin password to unlock screen. This normaluser and adminuser setting is the golden rule. – Boris Jul 17 '12 at 21:14
  • 1
    Fair enough, I just got an impression the OP was using the normaluser account for everyday work and admin account for performing administrative tasks, which does not really improve anything. On a multi-user machine this totally makes sense. – Sergey Jul 17 '12 at 21:57

12 Answers12

34

Terminology

In this answer:

  • normaluser is a normal user who is not an administrator and cannot run commands as root with sudo.
  • admin is an administrator who can run commands as root with sudo. (Of course, any graphical commands should use a graphical frontend like gksu/gksudo, and not sudo directly.)
  • anyapplication is the name of the graphical application normaluser wants to run as root. normaluser knows admin's password and has (presumably) been told s/he may use it for this purpose.

The Problem

The cause of your problem, and the reason most of the other answers so far don't work (with the exception of Marty Fried's excellent answer), is:

  • gksu can be configured to use either sudo or su as its backend. The default behavior of gksu in Ubuntu is to act as a frontend for sudo, not for su. That is to say that, by default, gksu and gksudo behave exactly the same. See the manpage.
  • normaluser is not an administrator and thus cannot run commands as root with sudo. sudo prompts for the password of the user running it, not the password of the user they want to become. Not being able to use your password to perform actions as people who aren't you is what it means to not be an administrator.
  • normaluser, provided it is not a Guest account, can run commands as another user with su, putting in the other user's password. But gksu acts as a frontend for sudo, not su.
  • normaluser cannot directly run any command as root, because normaluser cannot use sudo, and nobody can become root with su because there is no root password.

The Solution

The solution requires writing a command that performs two authentication steps:

  • normaluser must become admin to run a graphical command. To do this, normaluser must run gksu with the -w flag to make it run in su-mode instead of the default sudo-mode, and the -u flag to run the command as admin instead of root.
  • The command run as admin must invoke gksu without the -w flag to use sudo to become root.

Here's the command (yes, I have tested it ;-)):

gksu -w -u admin gksu anyapplication

You will be prompted for a password twice:

  1. First, you must enter admin's password, to let normaluser run a command as admin with the su backend.
  2. Second, you must enter admin's password, to let admin run a command as root with the sudo backend.

That's right. You enter admin's password twice.

Miscellaneous notes:

  • If you wish, you can replace the second gksu with gksudo to make it less confusing. In Ubuntu, they are equivalent. (You can also replace the first gksu with gksudo, but that would be extremely counterintuitive and confusing.)
  • -w is the short form of --su-mode.
  • -S is the short form of --sudo-mode but neither has to be used because sudo-mode is the default.
  • You may want to test this with some pretty harmless command first, to make sure it does what you want. (It will, but there's no need for you to trust me on that.) For example: 
    gksu -w -u admin gksu xclock
    xclock is a nice simple clock-window application.
Community
  • 1
Eliah Kagan
  • 117,780
12

One way that will probably work is to use "sux" rather than "su" when you first switch to the admin user. sux fixes the problem of running x applications from the spoofed user. It is in the standard repo, and can be installed by entering sudo apt-get install sux at a commandline.

Then, just use "sux" instead of "su" and it should work the way you expect.

Lets reuse the example of the application xclock:

sux admin
gksu xclock
Boris
  • 4,932
Marty Fried
  • 18,466
11

PAM can take care of it

This works for me on Ubuntu 16.04 (edit: it works too on 18.04 LTS):

put the line: 

session optional pam_xauth.so

somewhere in:

/etc/pam.d/su

and/or

/etc/pam.d/sudo

and then doing "su -" or "sudo su -" I can use graphical apps as root.

Boris
  • 4,932
Gerben
  • 136
7

pkexec

There is an ubiquitous alternative to kdesudo and gksu - pkexec which is from policykit-1 package that is required by lots of packages.

int_ua
  • 8,574
  • I recommend expanding this answer to explain how a regular user (who is not an administrator and cannot become root with sudo or polkit), who knows the password of an administrator (i.e., of someone who can become root with sudo or polkit), can use pkexec to run a graphical program as root. That's what the question here is asking. It's not clear to me that pkexec will do this, at least without extensively editing configuration files, especially since pkexec cannot generally be used to run arbitrary graphical programs (without polkit profiles) at all. Is there a way? – Eliah Kagan Aug 17 '14 at 08:07
  • @EliahKagan This works on Ubuntu with default configuration - just run pkexec command and it works. The configuration is in the file /usr/share/polkit-1/actions/org.freedesktop.policykit.policy which is installed by the named package. And it actually require you to write the admin password only once – pqnet Aug 17 '16 at 01:36
  • 2
    if you got an error "cannot open display" then try to pass DISPLAY and XAUTHORITY env variables e.g. pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY nautilus – Sergey Ponomarev Dec 24 '19 at 23:05
2

For me worked this:

pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY yourcommand commandoption1 commandoption2

Here you have to replace the yourcommand commandoption1 commandoption2 part with real command and it's args

Sergey Ponomarev
  • 334
  • 2
  • 8
  • 1
    This would actually work! All the other gksu etc. will not work since no major distros ship these tools. – SLS Apr 07 '21 at 23:56
2

In Lubuntu, there's a tool called lxqt-sudo. It's in the official repositories. It works!

lxqt-sudo/groovy, now 0.15.0-0ubuntu1 amd64, is a Graphical Qt frontend for plain sudo.

https://packages.ubuntu.com/focal/lxqt-sudo

BeastOfCaerbannog
  • 14,585
Veritas Eskell
  • 21
2

You can use sudo with GUI using the options -sE, as follows:

sudo -sE GUI_CMD

For example, if you want to run nemo as root:

sudo -sE nemo

AKMalkadi
  • 141
0

I would typically use the following logic in my scripts so that they will always request privilege escalation themselves using the appropriate method:


load_function_library

if [[ ${UID} -eq 0 ]] ; then
    # Execute only in the case of elevated privileges:
    if hash dialog ; then
        if ( dialog --backtitle "$( basename $0 )" --title "${BRAND} tools updater: NOTICE!" --yesno "\nMay I update the ${BRAND} OEM tools on your system now?" 20 80 ) ; then
            clear && do_update
        else
            clear && exit
        fi
    else
        echo -e $YELLOW
        echo "Hello $SUDO_USER ... I am going to update the OEM tools now..."
        echo "To cancel this, just close the terminal or press "CRTL C"."
        echo " "
        read -p "Press [ ENTER ] to continue with update"
        echo -e $ENDCOLOR
        do_update
    fi
else
    # If privileges are not elevated; then request elevation using the appropriate method:
    if echo $(systemctl get-default ) |grep graphical ; then pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY $0 ; else ensure_admin ; fi
    exit
fi
SLS
  • 168
  • 12
0

Instead of 

su admin
gksu anyapplication ...

I suggest you to try gksu -u admin anyapplication, where you do everything using the gksu command itself. Also please make note that you have to enter the password of the user mentioned in the command, ie, in this case you have to enter admin's password.

l0n3sh4rk
  • 444
  • 2
  • 7
  • 1
    On a default-configured Ubuntu system, if normaluser runs gksu -u admin anyapplication it will prompt for normaluser's password to become admin using the sudo backend, just as gksu anyapplication would prompt for normaluser's password to become root using the sudo backend. Both will fail for the same reason--normaluser does not have the power to run commands with sudo. – Eliah Kagan Jul 17 '12 at 20:55
-1

You should use:

gksudo AppName

This brings up a graphical password request first (your user's password), and then starts the GUI-app as root (I just tried, it really does. Funny thing: I tried gksu AppName immediately thereafter, and that worked as well -- as it is probably supposed to, as the "gk" prefix suggests. So I'm not completely sure where your problem may be located).

Izzy
  • 3,570
  • 1
    it works in your case because you have tried from an admin user session with sudo right. What about from a non admin user session without sudo right? – Boris Jul 17 '12 at 20:23
  • i used gksudo from a normal terminal window with a non-admin user (my own user). You are correct however for the second try, as I still had sudo perms then. But the problem of Boris is a different one: his app cannot connect to X, which in my case worked both times. As you can see from the original question, sudo in text mode is working for him. – Izzy Jul 17 '12 at 21:00
-1

There is only one super user and that is root.

User 1 is an admin and has sudo rights.
User 2 is not an admin and does not have sudo rights.

Try logging in as user 1 then using the command 

gksudo app-name

(replacing app-name with the app name)
Hope that helps - let me know. :o)

EDIT : More info as requested

If it is just you on the computer,
then using user 1 (who has permission to use sudo)
is no different to using user 2 (who does not have permission to use sudo).
User 1 has the same rights as user 2.
Unless user 1 issues a command prefixed with sudo and / or provides their password to allow applications to run with root privelages.
The only difference is that user 2 cannot run apps as root.

Hope that helps explain it a bit for you. :o)

Fernhill Linux Project
  • 3,899
  • thanks for the clarification between super user and admin, I will edit my question. What do you mean by "logging as user 1" => open the session with user 1 ? well that is what I would like to avoid. – Boris Jul 17 '12 at 20:21
  • added more info to answer as requested :o) – Fernhill Linux Project Jul 17 '12 at 20:28
  • well my wife and my kids are using the user2 with the autologin, so I rather like not having sudo right with that user. – Boris Jul 17 '12 at 20:41
  • Sounds like a good idea - I have kids too ;o). Did you try logging in as user1 yet and and running the command? – Fernhill Linux Project Jul 17 '12 at 20:43
  • 1
    Yes I can but it is painful to change user session. I usually have to do it several times: go on admin session to define some settings, switch to normal user session to test, and again and again, it is very nice to be able to do that staying on the normal session. Most of the time I handle it with su admin + sudo ... example sudo vi file, except for application with GUI – Boris Jul 17 '12 at 20:51
-2

Here's the command to accomplish this.

gksu app-name

Run it without running su first. You only need to run the above command from a normal user session and the application will be run as root.

SirCharlo
  • 39,486