Comment 28 for bug 15093

I don't like that patch because it only fixes the problem in pam_thinkfinger's case, where it asks for the password or your finger to be swiped.

For example, *any* other pam modules that display something to the console, but isn't asking for the password will be overridden by sudo, thereby springing gksudo up, prompting the user to input a password to put in their password anyway - misleading, and possibly a security risk also.

One example where this happens is using the UBEK binary driver and pam_bioapi - the console version outputs to the console:
"Please wait...
Put finger
"
which I assume would be overridden by the patched sudo, and triggering gksudo. Similarly, the GUI version does not output anything to the console - so I'm also guessing that even the patched sudo won't save us there.

My current personal solution has been to hack libgksu to keep checking sudo's output until it's either killed (i.e. another pam module authenticated successfully, the application was run, and has now exit, meaning sudo can exit too), or until GNOME_SUDO_PASS has appeared (in which case PAM modules have failed, and it is now falling back to password) - and only then does it open the prompt. Currently, gksudo checks sudo's output using a non blocking method - if data doesn't exist, then it gives up - I've changed this so that it now waits for new data.

However, this won't make pam_thinkfinger work without patching sudo, but I feel it is a more elegant solution - given that (I'm assuming) it will work for any other PAM modules that fall back onto a standard sudo prompt. I'm also getting feedback in the form of the driver GUI.

Ideally, I feel that if gksudo is to continue being a wrapper around sudo, it should launch a "terminal" of some sort (similar to the embedded terminals that synaptic and dpkg use), which would show the output of any PAM modules, instead of its current password-only dialog.