Graphically ask for password in a bash script and retain default sudo timeout setting

9,068

Solution 1

I add this to my bash script:

# ask for password up-front.
sudo -v
# Keep-alive: update existing sudo time stamp if set, otherwise do nothing.
while true; do sudo -n true; sleep 60; kill -0 "$$" || exit; done 2>/dev/null &

Found it here:

https://serverfault.com/questions/266039/temporarlly-increasing-sudos-timeout-for-the-duration-of-an-install-script

https://gist.github.com/cowboy/3118588

I use another script to launch my main script and I use a .desktop file to launch that helper script. It's not very straightforward, but it can be made to work 100% GUI. I'm still looking for the perfect solution, but this is doing the trick for now.

Solution 2

How about gksudo?

$ gksudo your_app_launcher.sh

It does show a graphical dialog for safely entering the administrator password.

Share:
9,068

Related videos on Youtube

Jarek
Author by

Jarek

You may be interested in the story of SE moderator Monica Cellio and how she was unfairly treated by the corporate management of this site. More info here. An update is available. Let's hope we can cultivate a more fair environment for content creators and moderators going forward.

Updated on September 18, 2022

Comments

  • Jarek
    Jarek over 1 year

    The sudo -A (SUDO_ASKPASS) option apparently causes sudo to lose the timeout (e.g., timestamp_timeout) setting.

    I want to use the sudo -A option but I want to retain the default timeout (e.g., 15 minutes on Ubuntu) in a bash script. I want to ask for the user's password securely and in a GUI dialog, but I only want to prompt once for my script (not 50+ times).

    Furthermore, I do not want to run my entire script as the root user because I just think that is a bad idea. Furthermore, files created by my script have the wrong ownership in this case.

    The sudo -A option would work for me if it retained the default timeout.

    From the sudo manual:

    Option: ‑A

    Normally, if sudo requires a password, it will read it from the user's terminal. If the ‑A (askpass) option is specified, a (possibly graphical) helper program is executed to read the user's password and output the password to the standard output. If the SUDO_ASKPASS environment variable is set, it specifies the path to the helper program. Otherwise, if /etc/sudo.conf contains a line specifying the askpass program, that value will be used. For example:

    # Path to askpass helper program
    Path askpass /usr/X11R6/bin/ssh-askpass
    

    BTW, kdesudo has this same problem -- it requires the password every time it is called, even if just a second later in the same script.

    I'm using Kubuntu 12.04 64 bit.

    Here are full working example of all parts of the solution. It consists of a bash script, a "myaskpass" script as suggested here, and a ".desktop" file. The whole things should be 100% GUI (no terminal interaction at all), so the .desktop file is essential (afaik).

    $ cat myaskpass.sh 
    #!/bin/bash
    kdialog --password "Please enter your password: "
    exit 0
    
    
    $ cat askpasstest1.desktop 
    #!/usr/bin/env xdg-open
    [Desktop Entry]
    Comment=SUDO_ASKPASS tester1
    Exec=bash /home/user/test/askpasstest1.sh
    GenericName=SUDO_ASKPASS tester1
    Name=SUDO_ASKPASS tester1
    NoDisplay=false
    Path[$e]=
    StartupNotify=true
    Terminal=false
    TerminalOptions=
    Type=Application
    Categories=Application;Utility;
    X-KDE-SubstituteUID=false
    X-KDE-Username=
    

    And a test script itself. This one will ask for your password twice when using this solution.

    #!/bin/bash
    
    sudo -k
    SUDO_ASKPASS="/home/user/test/myaskpass.sh" sudo -A touch filemadeas_askpass1
    touch filemadeas_regularuser1
    SUDO_ASKPASS="/home/user/test/myaskpass.sh" sudo -A touch filemadeas_askpass2
    touch filemadeas_regularuser2
    ls -la filemadeas* > /home/user/test/fma.log
    kdialog --title "Files Created" --textbox /home/user/test/fma.log 640 480
    sudo rm filemadeas_*
    rm fma.log
    
    exit 0
    
    • Admin
      Admin almost 11 years
      Is gksudo not an option here? linux.die.net/man/1/gksudo
    • Admin
      Admin almost 11 years
      I'm on KDE, so gksudo isn't an option for me, but I was told it works the same as kdesudo. kdesudo suffers the same problem I describe above. I was testing sudo -A as an alternative to kdesudo and it is better for my situation, but it doesn't solve the timeout issue (at least so far).