libgksu fails to start many programs, fails with: assert g_str_has_prefix str != NULL

Bug #501559 reported by Scott Balneaves
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
libgksu (Ubuntu)
Fix Released
High
Michael Vogt
Lucid
Fix Released
High
Michael Vogt

Bug Description

libgksu2-0 has changed from the 2.0.12 to 2.0.13 release, specifically, in it's handling of forkpty for interacting with sudo: it's now an option which ISN'T enabled by default.

In order to restore the previous behavior:

change the rules file in debian/ to read:

DEB_CONFIGURE_EXTRA_FLAGS := --disable-gtk-doc --enable-gnome-keyring --enable-sudo-forkpty

This will restore the previous behavior.

Simplest test to verify broken vs. fixed behavior:

gksu gksu ls ---> will give the assert error

after enabling sudo-forkpty

gksu gksu ls ---> returns directory listing, as it does on Karmic.

Please fix, blocker for sabayon in lucid

Changed in libgksu (Ubuntu):
importance: Undecided → High
milestone: none → lucid-alpha-2
status: New → Confirmed
Michael Vogt (mvo)
Changed in libgksu (Ubuntu):
assignee: nobody → Michael Vogt (mvo)
Michael Vogt (mvo)
Changed in libgksu (Ubuntu Lucid):
status: Confirmed → In Progress
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package libgksu - 2.0.13~pre1-1ubuntu3

---------------
libgksu (2.0.13~pre1-1ubuntu3) lucid; urgency=low

  * 25_fix_g_str_has_prefix_assert.patch:
    - fix assert failure when not running in forkpty mode
      (LP: #501559)
 -- Michael Vogt <email address hidden> Tue, 05 Jan 2010 11:34:07 +0100

Changed in libgksu (Ubuntu Lucid):
status: In Progress → Fix Released
Revision history for this message
Scott Balneaves (sbalneav) wrote :

Tested, still not working with sabayon.

Sabayon tends to do a lot of logging to stderr, which seems to confuse gksu without the --enable-sudo-forkpty

Is there a reason why we can't enable that flag to get the previous behavior?

Changed in libgksu (Ubuntu Lucid):
status: Fix Released → Confirmed
Revision history for this message
Scott Balneaves (sbalneav) wrote :

Looking at the code, a bit earlier, if you run with --forkpty, it actually captures and handles child_stderr

If you run without it, I'm not even sure it's keeping stderr open. So, once the buffer fills up...

Revision history for this message
Scott Balneaves (sbalneav) wrote :

ok, unless I'm missing something, the dichotomy comes about this way:

WITH the forkpty option ->

try to do a sudo -v to obtain ticket, only read a small amount of stderr
if sudo -v succeeds, then do a g_spawn_async of the actual command (since we've obtained a ticket, this doesn't ask for the password)

WITHOUT forkpty ->

try to fork/exec the command directly, only read a small amount of stderr to handle sudo problems, any other stderr output results in EPIPE

According to a bug that mvo pointed me to, the impetus for dropping forkpty was that changing the pty buggered up some sudo options. However, I'm assuming the first method of getting the ticket first was OK.

That being said, this patch implements the same program flow under the pipe version, as the forkpty version.

Revision history for this message
Scott Balneaves (sbalneav) wrote :

Oh, forgot to note: this patch solves my problem. mvo?

Revision history for this message
Scott Balneaves (sbalneav) wrote :

Wait, no.

That patch is correct if you run gksu from a terminal.

If it's started from a .desktop file (sabayon's .desktop's command is "gksu sabayon") it doesn't pop up with anything.

Still stumped... but the above patch gets us closer, I think

Revision history for this message
Scott Balneaves (sbalneav) wrote :

ah:
buffer: -: no tty present and no askpass program specified-

Revision history for this message
Scott Balneaves (sbalneav) wrote :

ok, try this one:

Tested and works from both tty, and via .desktop, and I even tested with tty_tickets. Seems ok.

Revision history for this message
Michael Vogt (mvo) wrote :
Revision history for this message
Michael Vogt (mvo) wrote :

@Scott: I think (I need to look again more carefully) that the patch in comment #8 will only output stderr when the child exited while the patch in #9 should do that continously. That needs to be double checked with a small script like:
#!/bin/sh
for i in $(seq 10); do echo "stdout $i"; echo "stderr $i" 1>&2 ;sleep 0.5; done

Revision history for this message
Scott Balneaves (sbalneav) wrote :

Yup! This one works as well. A keeper!

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package libgksu - 2.0.13~pre1-1ubuntu4

---------------
libgksu (2.0.13~pre1-1ubuntu4) lucid; urgency=low

  * 26_restore_stderr_output.patch:
    - output stderr from the sudo child (as pre-lucid versions did)
       LP: #501559
 -- Michael Vogt <email address hidden> Fri, 08 Jan 2010 09:22:23 +0100

Changed in libgksu (Ubuntu Lucid):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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