L'esecuzione di Sudo con Exec opera in modo molto diverso da distro a distro

[vuott]

Riporto questa discussione apparsa sulla Mailing List internazionale:


« Last post on this (see topic: Strange problem with running Shell on
Fedora) my executable run on Fedora.
Day after it didn't run anymore (and I changed nothing).
So I coded, tested, recoded and tried all kind of things, but it just
won't work.

So I decided to do some testing with code initially working on my
development system. And the results are confusing at least.

For example why am I getting different results running:
sudo -s id -u
on some systems for every time I run it (without any changes to code at
all)?

Attached gsudo.png shows the desired result (just for testing sudo)

Been playing and testing this for over 12 hours in total last few days
and whatever I do nothing seems to work on all systems.

Code run (see attached source archive):

Tested this on a bunch of distro desktop combinations running from both
IDE and gambas executable:

Added is my results and I'm stunned by them as to me they make no sense
at all!!

1. Code seems to work all the time on all Ubuntu based distros except
those running LXDE, Xfce and RazorQt
2. Code doesn't seem to work (or not all the time) on LXDE, Xfce
desktops no matter what distro
3. Code doesn't seem to work (or not all the time) on Debian

Tests result in attached file can be:
ok -> run as expected and with results returned

OR

hung -> no reaction from application at all -> need to force quit the
executable or click STOP button in IDE menu bar. Can wait all I want for
something to happen

Is this a problem/bug in Gambas in combination with certain desktops?
Am I doing something wrong?
Why does it work and on a next run not work or vice versa?

Hope someone can figure this out as I'm out of options...

If you need more details, just let me know and I'll post them

--
Kindest regards.

Willy Raets, »

[pastrank]

Hope someone can figure this out as I'm out of options...

O che sono solo io a pensare che uno potrebbe lanciare il programma con gli appropriati permessi (ovvero, da root o sudato), e poi fregarsene di tutte queste minc bischerate? Se no, uno prende visudo e da i permessi a quel che vuole, ma che uno debba per forza lanciare un programma come utente e poi shellare come su mi sembra non necessario.

[vuott]

...continua......


« It is getting more crazy by the minute:

This is part of the code of previous version posted (version 0.0.5):

Codice: gambas [Seleziona]

Public Sub btnSudo_Click()

  If IsNull(txtPassword.Text) Then
    Message.Info("First enter a password")
  Else
    txaOutput.Clear
    txaOutput.Text = "Ready to rumble..\n\n"
    $hProcess = Exec [System.Shell, "-c", "sudo -s id -u"] For Input
Output As "Process"
    Print #$hProcess, txtPassword.Text
  Endif
 
End

To pin point where it goes wrong I added a output to txaOutput
(TextArea) before and after the passing of the password.
See ExpectedOutcome.png for what is should show when run successfully.

Changed the code to (version 0.0.6):

Codice: gambas [Seleziona]

Public Sub btnSudo_Click()

  If IsNull(txtPassword.Text) Then
    Message.Info("First enter a password")
  Else
    txaOutput.Clear
    txaOutput.Text = "Ready to rumble..\n"
    $hProcess = Exec [System.Shell, "-c", "sudo -s id -u"] For Input
Output As "Process"
    txaOutput.Text &= "Passing password..\n"   '<-- ADDED
    Print #$hProcess, txtPassword.Text
    txaOutput.Text &= "Password passed..\n\n"  '<-- ADDED
  Endif
 
End

Attached the source code archive version 0.0.6

Next tested this on my Gambas 3.3.4 running distributions. Note the
difference
Test results version 0.0.5 (see previous post):
GAMBAS 3.3.4
------------
1. Linux Mint 13 - Mate 1.4.0 - sudo version: 1.8.3p1 (Ubuntu 12.04
based)
run 1 -> ok                run 1 -> ok
run 2 -> ok                run 2 -> ok
run 3 -> ok                run 3 -> ok
run 4 -> ok                run 4 -> ok
run 5 -> ok                run 5 -> ok

2. Lubuntu 12.04 - LXDE 0.5.8 - sudo version: 1.8.3p1 (Ubuntu 12.04
based)
run 1 -> hang!!                run 1 -> ok
run 2 -> hang!!                run 2 -> hang!!
run 3 -> hang!!                run 3 -> hang!!
run 4 -> hang!!                run 4 -> hang!!
run 5 -> hang!!                run 5 -> hang!!

3. Linux Mint 13 - Xfce 4.10 - sudo version: 1.8.3p1 (Ubuntu 12.04
based)
run 1 -> hang!!                run 1 -> hang!!
run 2 -> ok                run 2 -> hang!!
run 3 -> hang!!                run 3 -> hang!!
run 4 -> hang!!                run 4 -> hang!!
run 5 -> ok                run 5 -> hang!!

Test results version 0.0.6 (see attachement)
GAMBAS 3.3.4
------------
1. Linux Mint 13 - Mate 1.4.0 - sudo version: 1.8.3p1 (Ubuntu 12.04
based)
run 1 -> ok                run 1 -> ok
run 2 -> ok                run 2 -> ok
run 3 -> ok                run 3 -> ok
run 4 -> ok                run 4 -> ok
run 5 -> ok                run 5 -> ok

2. Lubuntu 12.04 - LXDE 0.5.8 - sudo version: 1.8.3p1 (Ubuntu 12.04
based)
run 1 -> ok                run 1 -> ok
run 2 -> ok                run 2 -> ok
run 3 -> ok                run 3 -> ok
run 4 -> ok                run 4 -> ok
run 5 -> ok                run 5 -> ok

3. Linux Mint 13 - Xfce 4.10 - sudo version: 1.8.3p1 (Ubuntu 12.04
based)
run 1 -> ok                run 1 -> ok
run 2 -> ok                run 2 -> ok
run 3 -> ok                run 3 -> ok
run 4 -> ok                run 4 -> ok
run 5 -> ok                run 5 -> ok

Will be testing further, but there is improvement as all seems to work
now all of a sudden just by adding two lines of code to check what is
happening, Xfce and LXDE seem to be doing fine....??!!

Anyone who can make some sense out of this? Explain what is happening
and why?

I'll be back with a Gambas 3.4.0 report later...wonder what happens
there..


--
Kind regards,

Willy (aka gbWilly) »


« I didn't read all your project yet, but by seing that code, I can tell
you that what you wrote cannot work reliably.

Why? As the process execution is not synchronous, 'sudo' may not be yet
ready when the "Print #$hProcess,..." line is executed.

Instead, you must catch the output of 'sudo' in the Process_Read event,
and only sends the password after sudo has emitted its "Password:" prompt.

Look the 'VersionControl.Run' method in the IDE source code: it runs a
subversion command that way. In the Process_Read, it watches the output
of the svn command, and sends the password as soon as the command emits
a password prompt (which may come almost at random with the 'svn' command!)

So rewrite your code the way I told you before doing all your checks again.

Regards,

--
Benoît Minisini »


« Ok, now I get the problem.

I studied the code you suggested and implemented the passing of the
password in the Read event at the proper moment and it works on both my
development machine and the Fedora-LXDE box...YESSSS!!!

The code (for those ever running into the same problem):
----------------------------------

Codice: gambas [Seleziona]

Private $hProcess As Process
Private $bFound As Boolean

'txtPassword -> TextBox to enter password
'txaOutput -> TextArea to feed back the output of the process

Public Sub btnSudo_Click()

Dim sCommand As String 
If IsNull(txtPassword.Text) Then
    Message.Info("First enter a password")
  Else
    $bFound = False
    sCommand = "id -u"
    txaOutput.Clear
    $hProcess = Exec [System.Shell, "-c", "sudo -s " & sCommand] For
Input Output As "Process"
  Endif
 
End

Public Sub Process_Read()

  Dim sLine As String
  Dim iB As Integer
  sLine = Read #Last, -256
  If Not $bFound Then
    If Len(sLine) <> 0 Then
      iB = InStr(sLine, "password for", 1)
      If iB > 1 Then
        txaOutput.Text &= "Passing password...\n"
        txaOutput.Insert(sLine & "\n")
        Print #$hProcess, txtPassword.Text
        $bFound = True
      Else
        txaOutput.Insert(sLine & "\n")
      Endif
    Endif
  Else
    txaOutput.Insert(sLine & "\n")
  Endif
 
End

Public Sub Process_Error(sError As String)

  txaOutput.Insert("ERROR: " & sError & "\n")
 
End

Public Sub Process_Kill()

  txaOutput.Insert("Killed\n")
 
End

----------------------------------
Note:
The sCommand = "id -u" can be replaced by any command you would like to
run using sudo like sCommand = "apt-get update" for example (on Debian
and Ubuntu based) will work.

Thank you for the insight Benoît, I learned a lot...

--
Kind regards,

Willy (aka gbWilly) »

[vuott]

...continua......


« Hi Willy,

Yes, sudu is very different on different distros!  Completely different
in fact.  The last time I counted (about a year ago), there were 5
different versions over the dozen or so distros we support.  These
differences lie in the absolute base code.  That is, they are actually
completely different programs not different versions of the same base
code.

So much for the bad news.

The best answer we have found is to use gksu.  This separates the
privilege escalation from the actual execution stream, but note that the
user has to enter the privilege escalation password every time it is
invoked (which some consider to be "not a bad thing").  Since deciding
on that route, it has worked "almost" seamlessly on all our client's
distros with little support effort. I say "almost" because there is
something about older versions of ubunti that corrupt the use of su
(which is what gksu uses to initiate the execution thread).

gksu appears to us to be fairly desktop agnostic (within reason). gsudo
and its' (dare I say) inbred cousins don't seem to be so.

Since adopting that model, i.e. separating the privilege escalation from
the execution stream, we have had very few "help me" support calls for
the dozens of gambas Shell and Execute calls our stuff makes.

Also and without wanting to get into the age old su vs. sudo battle! I
just want to say one thing. At least su based utilities ....
(Oh bugger, that's just going to start it all again.)
Suffice to say, guess which side I'm on.

and finally, "gksu" - it works for me!

hth
Bruce »

[9bit]

Grazie!!