TL;DR: What's the new right way to do a graphical sudo from a shell script?


I just upgraded from kubuntu 16.04 to 18.04 and I'm doing the normal triage.

kdesudo is gone in 18.04 (unmaintained).

I use it a lot in bash scripts with GUI i/o.

Some post said use kdesu - which seems weird. I seem to recall that it messes with the effective user or something like that.

That's not installed in my PATH.

I found it at

bigbird@sananda:~/pq$ ls -l /etc/alternatives/kdesu
rwxrwxrwx 1 root root 41 Aug 19 03:23 /etc/alternatives/kdesu -> 

which still says kde4.

I tried sudo -A ls

and it said

bigbird@sananda:~$ sudo -A ls
sudo: no askpass program specified, try setting SUDO_ASKPASS

I went in a few circles looking at ksshaskpass and ssh-askpass, but both say they're not intended to be called directly.

I am not doing anything with ssh.

I need this for bash scripts that do almost everything as a normal user and then run one or two commands as root. These scripts are often launched from desktop icons where there is no terminal window open (and I don't need or want one.) They often use yad (like zenity or kdialog) to interface with the user.

  • 1
    What about plain old sudo -H?
    – DK Bose
    Commented Aug 20, 2018 at 8:56
  • @DKBose - didn't know about that, but it doesn't solve the primary problem of getting a secure password from the user (me) when there's no terminal/CLI open.
    – Joe
    Commented Aug 20, 2018 at 9:38
  • I finally wrote a bash kdesudo() function that I use frequently. There was a link buried in the comments to the accepted answer. Here's the latest version: pastebin.com/GKtZa1px .
    – Joe
    Commented Oct 16, 2019 at 14:47

4 Answers 4


As you have discovered, you can use the -A option with sudo, but you need a gui method of supplying the password to sudo.

You can write such a tool anyway you want, as long as it passes the password back to sudo on stdout. I use a simple solution which someone suggested to me a very long time ago, that uses kdialog, and like all simple solutions, it has remained my go to ever since.

So create yourself a simple kdialog script, such as this

    kdialog --password "Password required to proceed"

Now you use this with sudo like this

    export SUDO_ASKPASS=<path to your kdialog script>
    sudo -A foo

You can of course use any language you want to for your gui password provider if you don't have kde

EDIT: Solution to bypassing sudo passwd_tries

So that you can just ask for the password once only (as you want to do), you can capture the password in a variable within the script and pass that variable directly to the sudo command using the -S switch.

This has the advantage that it ignores the sudo passwd_tries rule, and still requires the interactive password input, so the password is not stored within the script.

PASSWD=$(kdialog --password "sudo password required")
echo $PASSWD | sudo -S foo

You can also do it directly on a line, if you do not need multiple sudo commands in the script, like this

echo $(kdialog --password "sudo password required") | sudo -S foo

And of course you can use your own kdialog script that we discussed earlier in place of using kdialog here, if you want a standard kdialog prompt in all your scripts.

The problem bypassing sudo's passwd_tries, from my POV, is that if you get the password wrong, your script will continue processing any commands after the sudo command, so if the sudo elevated command was critical to the script's success then you have problems.

The caveat is that the password from kdialog (or alternative such as zenity) is written on stdout, something I should have mentioned before, so anyone that has captured the PID's stdout would see your password. But then any hacker on your system would be doing a lot more than just that.

  • +1 I was wondering if it could be so simple. I just hope there aren't any new security issues. If I do it this way, I'll put it in /usr/local/bin.
    – Joe
    Commented Aug 21, 2018 at 5:56
  • 1
    No security issues as there are no passwords stored anywhere, kdialog writes the password directly to stdout which is piped to sudo's stdin. The permissions for sudo last for exactly that call. Commented Aug 21, 2018 at 10:02
  • The dialog that kdialog presents has OK and Cancel buttons, but if I select Cancel, press Esc, or just click on the X in dialog frame, it still presents the dialog two more times. How do you tell it (or sudo), "No means no"?
    – Joe
    Commented Aug 25, 2018 at 4:06
  • sudo can be a demanding mistress lol, run the command sudo visudo -f /etc/sudoers and add the line Defaults passwd_tries=2 or whatever value you want it to be. Obviously if the default key already exists just edit the value to whatever you want it to be. Commented Aug 25, 2018 at 12:57
  • BTW: as this seems to be working how you wanted, you could accept this as the answer for future people in the same position. Commented Aug 25, 2018 at 13:31

Have you tried pkexec

  • 1
    Check this: askubuntu.com/questions/287845/how-to-configure-pkexec
    – papampi
    Commented Aug 21, 2018 at 10:08
  • @GunnarHjalmarsson Yes, I have, edited my original message as I set alias for it and forgot to post full command.
    – papampi
    Commented Aug 21, 2018 at 10:24
  • Can I ask why my answer is marked to get deleted? It brings up GUI dialogue box to enter password as its asked for.
    – papampi
    Commented Aug 21, 2018 at 13:30
  • I just read a bunch of links on this and my first impression is that it puts up a really ugly dialog and if you want to get rid of it, it's rocket science. It seems to be all about not running GUIs as root and I'm not doing that. I'm running relatively simple bash scripts that just need to be able to authorize individual commands without having access to a terminal.
    – Joe
    Commented Aug 22, 2018 at 2:40
  • I just tried this with one of my scripts. it works, but since the script had to issue more than one elevated command, I had to enter my password multiple times to do one thing. sudo and, by extension, its GUIs, had a timeout to avoid this problem. I do not want to elevate the whole script.
    – Joe
    Commented Aug 25, 2018 at 3:07

Not only kdesudo, but also gksu is also deprecated. These changes are at least mildly annoying. It seems the approach we are meant to take now is to utilize the admin:// prefix for example if you used to kdesudo gedit /etc/default/grub now you would instead gedit admin:///etc/default/grub This will definitely take some getting used to if I ever drop 16.04 for a "new and improved" version.

Another possible solution would be to simply launch the script in a terminal to begin with.

Source: https://www.linuxuprising.com/2018/04/gksu-removed-from-ubuntu-heres.html

  • My first attempt to use this ran into roadblock. I have a script called from a GUI that just wants to run iptables. No place to put an admin://.
    – Joe
    Commented Aug 25, 2018 at 3:01
  • @Joe updated answer
    – Elder Geek
    Commented Aug 25, 2018 at 11:26
  • Thanks for the elaboration, but while that would work and you can even configure a command to open in a terminal in the KDE menu/desktop, it would be seriously ugly and distracting. @nobodyspecial 's answer is better than that for my purposes. It doesn't inspire confidence (from users) if it looks like you had to turn the whole system upside down just to get a task done. I will try the admin:// thing in other situations where it would work. I had not seen that before.
    – Joe
    Commented Aug 26, 2018 at 4:38
  • @Joe I'm glad you found a solution that you are comfortable with. If that answer is acceptable to you should accept it by clicking the check mark next to it.
    – Elder Geek
    Commented Aug 27, 2018 at 17:57

I just found some answers here.

The gist of it is:

For now, a workaround is to find where kdesu is installed on your system

which you can do with

ls -l /etc/alternatives/kdesu

and then add an alias for kdesudo to $HOME/.bashrc or, if you use it, to $HOME/.bash_aliases.

The alias is

## Resurect kdesudo - this will probably fail eventually
alias kdesudo='/usr/lib/kde4/libexec/kdesu-distrib/kdesu'

making sure to adjust the path to kdesu to the one you found in the step above.

This will not work for some programs under KDE because

The KDE developers are working on a polkit route to allow temporary elevated privileges for other applications as they have already done for Kate. -- GreyGeek

and when they do, they disable direct elevation because (if it works right) you don't need it any more. The program just asks for a password when it needs to do a privileged operation. It remains to be seen how that will work in a script.

You must log in to answer this question.

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