Bug 550 - sudo does not abort askpass loop even if askpass program returns false
sudo does not abort askpass loop even if askpass program returns false
Status: RESOLVED FIXED
Product: Sudo
Classification: Unclassified
Component: Sudo
1.7.4
PC Linux
: low normal
Assigned To: Todd C. Miller
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-03-27 05:44 MDT by astrand
Modified: 2012-08-31 09:32 MDT (History)
0 users

See Also:


Attachments
Patch to treat the askpass cancel button like ^C (333 bytes, patch)
2012-03-27 12:44 MDT, Todd C. Miller
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description astrand 2012-03-27 05:44:22 MDT
askpass programs such as gnome-ssh-askpass and others usually have a Cancel button. When this button is pressed, nothing is printed to stdout, and the return code is non-zero. gnome-ssh-askpass returns 255. However, despite this sudo records this as a failed attempt and calls the askpass program again. Thus, it's not possible to "cancel" the authentication, like you can do with Ctrl-C. 

It would be better if sudo would abort the auth loop if the askpass program returns non-zero.
Comment 1 Todd C. Miller 2012-03-27 12:44:07 MDT
Created attachment 337 [details]
Patch to treat the askpass cancel button like ^C

The attached patch will cause the cancel button in the askpass program to be treated by the PAM conversation function like the user had entered control-C at the password prompt.
Comment 2 astrand 2012-04-02 08:59:45 MDT
Did a quick try with sudo-1.7.9, seems to work. As I understand it, this patch triggers EINTR if the output from the askpass program is empty. Thus the return code isn't used? Good enough for me; I suppose there's no need for sudo to handle zero length passwords?
Comment 3 Todd C. Miller 2012-04-02 10:18:16 MDT
A zero length password would show up as a newline from the askpass program so I don't think that is an issue.