gksudo fails if using libpam-krb5 for password auth

Bug #15093 reported by Stephen Shirley on 2005-04-07
64
This bug affects 1 person
Affects Status Importance Assigned to Milestone
GKSu
Fix Released
Unknown
gksu (Ubuntu)
Medium
Unassigned

Bug Description

When i run 'gksudo gedit' for example, the following happens in the terminal:
  diamond@weasel:~ $ gksudo gedit
  Password for dia
at this point, gksudo hangs, and anything i type appears after 'dia' on the above
line, and nothing bar ctrl-c will get it out of there. In /etc/pam.d/common-auth,
i have:
  auth sufficient pam_krb5.so use_first_pass
  auth required pam_unix.so nullok_secure
If i comment out the pam_krb5 line, the gksudo works as expected (a dialog pops
up asking for my password, and upon successfully entering the password, gedit
appears). Fwiw, if i do 'sudo gedit', the prompt i get is:
  Password for <email address hidden>:

My system is hoary/amd64, uptodate as of 5 minutes ago.
ii gksu 1.2.4-1ubuntu8 graphical frontend to su
ii libpam-krb5 1.0-10 PAM module for MIT Kerberos

Michael Vogt (mvo) wrote :

Thanks for your bugreport (and sorry for the late reply).

Can you please run:
$ sudo -p GNOME_SUDO_PASS gedit
and tell me what output you get?

thanks,
 Michael

Stephen Shirley (kormat) wrote :

Right:

  diamond@weasel:~$ sudo -p GNOME_SUDO_PASS gedit
  Password for <email address hidden>:

i.e. i get the correct prompt, and my password enters correctly (i.e. is not shown),
and gedit runs as root.

Jeff Layton (jtlayton) wrote :

Created an attachment (id=2359)
sudo patch to allow overriding PAM prompt

The problem seems to be that sudo does not respect '-p' or $SUDO_PROMPT unless
the prompt returned by the PAM module matches a particular format. This doesn't
seem like correct behavior -- you ought to be able to override it regardless of
the format. This patch corrects it so that if user_prompt is specified then we
use that instead of the pam prompt. This fixes the problem on my machine.

Jeff Layton (jtlayton) wrote :

Ahh to be clear, this patch is against:

sudo_1.6.8p5-1ubuntu2

Jeff Layton (jtlayton) wrote :

Created an attachment (id=2360)
sudo patch to allow overriding PAM prompt

Here's a slightly revised patch with cleaned up formatting and a change to the
comment.

Jeff Layton (jtlayton) wrote :

Created an attachment (id=2361)
patch with fixed comment

I really need to finish my coffee before posting. Here's a patch with a correct
comment.

Jeff Layton (jtlayton) wrote :

Went ahead and submitted this patch upstream as well:

http://www.sudo.ws/bugs/show_bug.cgi?id=180

Michael Vogt (mvo) wrote :

Thanks for your patch. It looks good, but I would like to see what upstream
thinks about it. The problem I see is that the domain information will be
dropped from the password prompt and that may cause trouble for the user. OTOH
it's something that was explicitly requested, so sudo should honor it.

Michael Vogt (mvo) wrote :

Latest comment from the upstream bugreport indicates that we can't use this
patch without breaking all challange-response authentication types.

Sean Middleditch (elanthis) wrote :

What about making gksu search for 'assword.*:' in the prompt instead of a
specific prompt? That should theoretically work for all password-based
mechanisms, no?

Jeff Layton (jtlayton) wrote :

Unfortunately, the prompt is governed by the PAM module. Most of them use a
variation of the expression you show, but if it shows something like:

Challenge 6789123hkjasd67:

That won't get it. What we need is a way to pass the prompt to gksudo (and to
gksu, I suppose) so it can be presented to the user correctly, and to have a
predictable prompt that these programs can look for to know when the auth token
needs to be entered.

We already allow certain % escapes with the sudo prompting mechanism. What may
be best is to add a new one for the PAM prompt string. You could then do
something like:

-p %p:GNOME_SUDO_PASS

and then strip out the ':GNOME_SUDO_PASS' and present the remainder to the user.
This means, however, some coordination between the two projects.

Michael Vogt (mvo) wrote :

*** Bug 16872 has been marked as a duplicate of this bug. ***

Michael Vogt (mvo) wrote :

I submited a new sudo patch to the sudo bugzilla (bug: #180). It is based on the
idea to add a POSTFIX string so that gksudo can present possible
challenge/reposonse information to the user.

Paul Dufresne (paulduf) wrote :

Just changing the status to reflect that patches exist, and seems to be still waiting to be approved by sudo team (upstream).

Changed in gksu:
status: Unconfirmed → In Progress
brettatoms (brettatoms) wrote :

I get the same behavior with pam_winbind as well.

brettatoms (brettatoms) wrote :

What's the latest with this bug and patch?

I think the importance of this bug should be upped since this breaks the entire System\Administration menu for anyone authenticating using via pam-krb5/windind and possibly others. This means most people in an "enterprise" environment authenticating against a Windows server can't run any apps from the menu that require root access.

levien (levien) wrote :

I agree with brettatoms, it is important to fix this issue if Ubuntu is to be usable in anything other than a stand-alone desktop environment. I am currently working with a small NGO to try and replace their ancient Windows 98 installations with Ubuntu 7.04. We authenticate the Ubuntu machines against a windows domain server. I now work around this bug by installing a patched copy of sudo in /usr/local/bin, and replacing /usr/bin/sudo with a symlink to the patched version. But anyone will agree that this is hardly an elegant solution...

-L.

Eddie Hung (eddieh) wrote :

I am experiencing a similar bug: this time using pam_bioapi (to support fingerprint readers), version 0.4.0.
The problem I am having is that gksudo does not pop up to ask for a password once the fingerprint dialog is aborted, as it would be expected to do.
My common-auth is as follows:
auth sufficient pam_bioapi.so {5550454b-2054-464d-2f45-535320425350} /etc/bioapi/pam/biodata.db :0

auth required pam_unix.so nullok_secure
gdm, and console-run sudo perform as expected - cancelling the fingerprint dialog and it will ask for a password. However, running gksudo from console results in:
# sudo -l
# gksudo gedit
<fingerprint dialog pops up - after exiting that>
GNOME_SUDO_PASS
at which point it echoes any characters I type at it (meaning that it's not asking for a password), including new line characters. The only way to abort this is to press Ctrl+C.
Note also that the screen is not blanked during the fingerprint dialog (separate bug?)
Running gksudo from a launcher has the same effect - but obviously no console output.
Does anyone know what GNOME_SUDO_PASS means? I've asked the google oracle, but that hasn't got me anywhere.
I can confirm that gksudo works perfectly well without the pam_bioapi line, and it also works if I make it ask for the password first, by changing common-auth to:
auth sufficient pam_unix.so nullok_secure

auth sufficient pam_bioapi.so {5550454b-2054-464d-2f45-535320425350} /etc/bioapi/pam/biodata.db :0

auth required pam_deny.so
gksudo does blank the screen and the password dialog appears, and pressing enter results in it unblanking and the fingerprint dialog appearing - this is my current solution, but far from ideal as I would like the password to back the fingerprinting.
It is also worth mentioning that this is also the case with pam_thinkfinger (an alternative fingerprinting "driver") which does not implement a separate fingerprinting dialog - gksudo does not appear at all, and after a successful fingerprint read gksudo does not exit - and a killall is required to bring the authenticating application up - though this also may be a error with pam_thinkfinger (version tested: 0.3.0).
All in all, I think we can conclude that gksudo (which from what I understand, is simply a wrapper for the console based sudo) does not support external pam modules very well?

Eddie Hung (eddieh) wrote :

Oops, should have mentioned that I'm running the latest Feisty 32bit on an IBM Thinkpad X41.

levien (levien) wrote :

Have you tried a patched version of sudo? You can get Jeff's patch from http://www.sudo.ws/bugs/attachment.cgi?id=37
Get the source-package for sudo ("apt-get source sudo" or the latest tarball from http://www.sudo.ws/sudo/download.html), apply the patch, recompile and install (e.g. in /usr/local). You can rename the original sudo (in /usr/bin) to something like /usr/bin/sudo_original and then do "ln -s /usr/local/bin/sudo /usr/bin/sudo". That might solve your problem for the time being.. Of course this issue really needs to be addressed by Ubuntu / gksudo / sudo if more people are to use PAM authentication with Ubuntu.

-L.

Eddie Hung (eddieh) wrote :

Hello levien. Could you enlighten me as to what this patch does? (and how it solves my problem?) Regardless, I'm not particularly keen on modifying a very important part of the OS - the patch (and the problem!) seems to be introduced two years ago, and it still doesn't seem to be fixed, which is slightly worrying...

Sufflope (sufflope) wrote :

I experience problems with gksu and libpam-ssh.
I installed libpam-ssh, and made those changes :

add "@include pam-ssh-auth" at the beginning of /etc/pam.d/common-auth
add "@include pam-ssh-session" at the beginning of /etc/pam.d/common-password

GDM works fine (I log in with my SSH passphrase), so do sudo and the screenlock. However, programs in the Administration menu don't show up the password prompt.

levien (levien) wrote :

Hi Eddie,

Well, I'm no expert on this I'm afraid. But as far as I understand it the problem is as follows: gksudo is basically a graphical front-end for sudo, and therefore it needs to know when sudo asks for a password. PAM modules however present their own prompt, which may be quite different from the standard "Password:" one. If that happens, gksudo will not recognise the custom password prompt and will just keep waiting. The first patch just tells sudo to override the PAM prompt in such cases, so that gksudo will recognise it. The problem is that this breaks certain kinds of authentication (which of course is not a problem if you don't need those, as in my case). The second patch adds an option to sudo allowing for a postfix-string to be appended to the password prompt. gksudo can then simply wait for this string, and then pass its password to sudo. However, this patch is still waiting to be included in sudo. As it has been submitted in two years ago, it seems that the sudo developers do not consider it to be a priority feature.

So in short, the problem with gksudo and pam is not really a bug, it is just a result of the way gksudo is implemented as a front-end to sudo. The best way to get it fixed would be to let the sudo maintainers know that this is really a feature that people do need, and to help them test it. Here is sudo bugzilla link again: http://www.sudo.ws/bugs/show_bug.cgi?id=180

As for your problem, the patched version of sudo may or may not solve it. It probably depends on what kind of prompt the bioapi module presents, if any. I wouldn't be too worried about patching sudo though. You can easily see what the patch does just by looking at the code. Furthermore, you can always go back to the original sudo if it doesn't work. The only problem is that the link to the patched version will probably get overwritten if sudo is updated...

Best regards,
Levien

Hello. I am using krb5/winbind authentication, and having the same problem. I have tried the patch linked by levien, and it works well with local users, but completely breaks sudo for domain users (before applying the patch, i was able to use sudo with domain users, the problem was only with gksu).

Actually, I think it is a bug, because I have noticed the following:

In a default Ubuntu installation, sudo presents the prompt "Password:", with an uppercase "P". But after configuring pam-krb5, it presents the prompt "password:", with a lowercase "p".

I am sure this bug is extremely easy to fix for any who knows where in the source is located the prompt string. So PLEASE, you smart guys, fix it for us begginers! ;)

Thanks a lot.

Chris Lord (cwiiis) wrote :

There's another, safer patch on the sudo bug now ( http://www.sudo.ws/bugs/show_bug.cgi?id=180 ) that really ought to be applied - it will allow a very trivial patch to be applied to gksudo and fix any non-standard PAM authentication. Is there anything holding this back?

Eddie Hung (eddieh) wrote :

I don't think this is a bug with sudo - it's a bug inherently inside gksu(do).

As you may know, gksudo is simply a wrapper inside gksudo. It executes sudo with a -p parameter, asking it to override the default password prompt with the supplied argument.

In gksudo's case, it asks sudo to override the prompt with the string "GNOME_SUDO_PASS". If then checks to see if sudo says this - and if it does, then it knows that sudo is expecting a password, and grabs the screen and shows the dialog.

However, if it doesn't see this (for example, if thinkfinger prints "Password or swipe finger", of if pam_bioapi displays the driver GUI and displays nothing on the console), then it assumes that no password is necessary - and simply sits there waiting until sudo exits.

But in most cases, this never happens: if the fingerprint has failed, then most users will have opted to fall back onto password - in which case sudo will be waiting for a password that will never have the opportunity to be input.

The current workarounds work because:
a. sudo only overrides the prompt if it receives "Password:" from the password module - in which case changing pam_thinkfinger to output "Password:" (instead of its current "Password or swipe finger:" prompt) will cause it's prompt to get overridden to GNOME_SUDO_PASS, and so gksudo will show itself.
b. With the suggested patches - sudo overrides the prompt to say whatever is requested, regardless of what the module is saying.

Neither is the ideal behaviour - either a complete rewrite of gksudo (more specifically, libgksu is where this code is written) is required (i.e. make gksudo something more than a wrapper around a console-based sudo), or a better method of waiting for GNOME_SUDO_PASS should be implemented - currently I believe it reads the first 50 lines from sudo (whether sudo has displayed 50 lines or not), and if none of them say GNOME_SUDO_PASS, then it gives up and just assumes that no password is necessary, and waits until sudo exits. I'm thinking it should only read the line if it exists - because GNOME_SUDO_PASS eventually turns up once all the preceding PAM modules have finished. This can be verified by running gksudo in debug mode, and looking at the libgksu source.

Any other thoughts? I'm currently looking into modifying libgksu.

P.S. Sorry for such a long post!

Chris Lord (cwiiis) wrote :

The patch at ( http://www.sudo.ws/bugs/show_bug.cgi?id=180 ) would allow gksudo to append its 'GNOME_SUDO_PASS' text onto the end of whatever the authenticating pam module outputs, meaning any challenge-response authentication won't be broken, but gksu will still be able to scan for its special text. It could then even strip this text and output whatever sudo says too, rather than just 'Password' that it does currently.

I think applying this patch to sudo, then patching gksu to use the new functionality is the best course. If the sudo patch is unacceptable (why?), then the only other reasonable course of action would be to make gksudo more than just a sudo wrapper.

Personally, I have the patch applied that lets the sudo prompt be overriden in any case, as an interim solution (not being able to authenticate with gksu is a pretty major bug...)

Eddie Hung (eddieh) wrote :

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.

Yueyu Lin (popeyelin) wrote :

I also has the problem with the thinkfinger. I don't access the libgksu source codes so I don't know what happened in it.
I almost start to modify the thinkfinger source codes.
What I plan is to add a dbus server to listen it and modify the promote codes in pam_thinkfinger.c to call dbus method. Then the server may popup a hint dialog to ask user to scan his fingerprint.
Fortunately I search it in launchpad.
Now what I'm understanding is gksu will parse the input from sudo's output through the wrap pipe. While the PAM module invoke sudo, it doesn't pass the PROMPT as sudo -p PROMPT, so gksu cannot get anything and it will think it's unnecessary to ask for password?
But the PAM module will make sudo to input the words they set in their codes. So it's not possible for gksu to adapt all kinds of output.

In my opinion it's not only gksu's fault, of course it's not sudo's fault.
Currently I can't find gksu's source codes. But I think it's kind of inter-process problem. It will be better for gksu to know when sudo will ask for passwords instead of reading the sudo's output.

I think a temporary method is to grab all output from sudo and display to user until sudo exit.

A long term method is to change PAM module to enable something like hook or notifier to allow user to customize their modules interfaces instead of command line only.

Do you think it's ok to add a dbus support in the thinkfinger? After reading the bug, I'm considering if it's worth doing it.
I'm glad to help to do something if needed. Currently I can only modify the thinkfinger's prompt to "Password:", sigh.

Changed in gksu:
status: Unknown → Fix Released

Hello,

It seems that as of 2008-12-28 there's no proper solution to this problem yet. I'm having issues with the pam_fprint module and gksudo in Intrepid, and the sudo bug #180 is marked as fixed..

Is there anyone still interested about this?

mac9416 (mac9416) wrote :

Since Jeff's patch was rejected upstream, I am tagging this bug accordingly.

tags: added: patch-rejected-upstream
Changed in gksu (Ubuntu):
assignee: Michael Vogt (mvo) → nobody
status: In Progress → Won't Fix
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.