Graphically ask for password in a bash script and retain default sudo timeout setting
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://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.
Related videos on Youtube
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, 2022Comments
-
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 almost 11 yearsIs
gksudo
not an option here? linux.die.net/man/1/gksudo -
Admin almost 11 yearsI'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 testingsudo -A
as an alternative tokdesudo
and it is better for my situation, but it doesn't solve the timeout issue (at least so far).
-