Chiamare un programma Gambas con 'root'

[vuott]

Vi riporto questa discussione apparsa nel forum tedesco dei programmatori Gambas:

http://www.gambas-club.de/viewtopic.php?f=3&t=4622

[Michy9393]

Grande

[vuott]

L'argomento è stato inserito anche nella Mailing List ufficiale:


" Hi all,

last month I read a question at gambas-club.de about how to relaunch one's
program with root privileges if it was running without them. This was the
straw to break the camel's back :-)

As far as I can remember back, it was always a problem for the most to get
sudo or su do the right things when controlled manually (and even to decide
whether to use sudo or su).

The other option was to use gb.desktop's Desktop.RunAsRoot() which but only
supports su and needs pre-installed graphical tools. This was inherently
buggy on my system because gb.desktop does not recognise my DE. For some
reason, it always started "kdesvn" instead of "kdesu" to ask for my
password and kdesvn is, as you might guess from the name, not suited as a
replacement for kdesu. (I might as well have screwed up some configuration
files on my system to confuse the xdg scripts. I don't know/care. The main
point of this mail is:)

So I sat down and wrote some classes which do the stuff in pure Gambas:
- ask for the user's preferred method of authentication (su or sudo) (which
   is also saved as of version 0.1.2 if gb.settings is available);
- ask for the password;
- restart the program with root privileges giving feedback about the
   operation (user cancelled password input, user gave wrong password - or
   new process started successfully) to the old process which may then
   take an action like terminating itself or, e.g., run with reduced
   functionality if the user cancelled input, etc..

I hope these classes can make the "can you give me (please)" kind of
questions about this topic answered quicker in the future ;-)

If you think it's good enough and know a good place in the docs where I can
put this, please tell me. I think (but try to convince me of the contrary):

- people won't find it in "Application Repository";
- "Tutorials" just doesn't look right;
- "How To..." seems to target auxiliary topics like desktop integration and
   using unicode - in a "code snippet" manner.

I cannot promise to fix bugs you encountered but opinions are welcome ;-)

Regards,
Tobi "


" I have had a quick look at it and here are some observations.
1) Just because sudo is installed on the system it does not mean that
the current user is an allowed sudo user. If not then no matter what
they type in as a password, when they click OK, the program just
"disappears".
2) Related to 1. It should not assume, just because sudo is installed,
that sudo is the preferred method.
3) The Authentication form needs work. The labels are not visually
associated with the correct control. (This one was from Felicity, who
can pick these things out with a 3 second glance at a form).
4) I'd say "How To..." is the proper place for this, even if it is
populated mainly with code-snippet information. Reasoning: this is an
auxilliary topic and further it is an "advanced" (i.e. complicated)
topic.
5) Using this approach, the project concerned must use a gui, so it is
no good for command line applications.
6) There is a considerable security concern with using this approach,
since the password is being entered into a gambas control, in
_Authbox.class:

Codice: gambas [Seleziona]

 Public Sub btnOK_Click()
          $sResult = txtPassword.Text
        ' and now some code that will email me the IP address,
        ' user ID and root password
        ' ...
       
          Me.Close()
        End

So, I wouldn't trust a gambas app from someone else that popped up that
form.


Don't get me wrong, I'm not trying to be destructive.  I can understand
the "need" for privilege escalation within a gambas application. We have
had the same need for several years with our thoroughbred training
system.  My philosophy goes like this, if the entire application needs
to be privileged, then it should be installed as a root program i.e. let
linux take care of the problem.  On the other hand, if only part of the
program needs escalated privileges then that part needs to be
compartmentalised and the escalation confined within it. Think
        ./configure
        make
        su make install

I we wanted to write a gambas program to install gambas programs then
only that last step needs privileges. (In fact, we have written one of
these that we use to distribute updates to our clients. It also does a
lot of other things as well that don't need privileges. Here is the
relevant code:

Codice: gambas [Seleziona]

 ' 4) make install
  Select Case Desktop.Type
    Case "LXDE"
      Shell Subst("gksu -D Installer 'cd &1; pwd; make install'", sPath,
"")) To logger
      Print logger
    Case "KDE", "KDE4"
      Shell Subst("kdesu -n 'cd &1; pwd; make install'", sPath) To
logger
      Print logger
    Case "GNOME", "XFCE"
      Shell Subst("'cd &1; pwd; pkexec make install'", sPat>) To logger
    Case Else
      Print "Installer type for " & Desktop.Type & " is unknown"
  End Select

In other words, we let the standard mechanism for the desktop handle the
privilege escalation (and if that program mails the special password
somewhere, its not our fault!)

Anyway, that's just what I think.

cheers
Bruce

[vuott]

...continua...


" Doesn't happen here. My desktop user is not allowed to use sudo and if he
does (with whatever password), the program shows the "Oops, something went
wrong" box as wanted.

I wonder what's the matter with my code. The OP at gambas-club.de said the
program didn't even ask him for the password...?

> 2) Related to 1. It should not assume, just because sudo is installed,
> that sudo is the preferred method.

I thought I would be one of only a few who have sudo but don't use it
everywhere on a desktop computer :-) Noted and fixed.

> 3) The Authentication form needs work. The labels are not visually
> associated with the correct control. (This one was from Felicity, who
> can pick these things out with a 3 second glance at a form).

What do you mean? I have attached a picture of how it looks when running
over here. Anything distorted there I don't recognise?

> 4) I'd say "How To..." is the proper place for this, even if it is
> populated mainly with code-snippet information. Reasoning: this is an
> auxilliary topic and further it is an "advanced" (i.e. complicated) topic.
> 5) Using this approach, the project concerned must use a gui, so it is
> no good for command line applications.

Good point! However, it is not that easy in Gambas to manipulate the
controlling terminal (disable echoing to let the user type his password).
The only possibility I see, without using gb.ncurses, would involve some
Externs and the nightmare of looking at struct termios from Gambas...

> Don't get me wrong, I'm not trying to be destructive.  I can understand
> the "need" for privilege escalation within a gambas application. We have
> had the same need for several years with our thoroughbred training
> system.  My philosophy goes like this, if the entire application needs
> to be privileged, then it should be installed as a root program i.e. let
> linux take care of the problem.

That's what I would do at any rate but the OP wanted to start a Gambas
program with root privileges from the program itself. I really didn't think
about how good this idea would at all be :-)

> In other words, we let the standard mechanism for the desktop handle the
> privilege escalation (and if that program mails the special password
> somewhere, its not our fault!)

Looks pretty much like an enhanced Gambas port of the xdg-su script. As I
noted, on my system this would go to Case Else with a pristine Gambas
installation but with a small patch I made to gb.desktop it should work...

I drawback is that you have to code different things for different systems
which I ultimately wanted to circumvent with my _AuthBox written in Gambas
alone.

> Anyway, that's just what I think.

Yep, thanks. There are definitely some things I will change tomorrow.


Tobi "


" Jeez, that's complicated code!

I wrote my own version, (vedi allegato) this is perhaps a little simpler. Check it. ;-)

Otherwise. Your code:

Codice: gambas [Seleziona]

IIf(Application.Path Ends ".gambas", "/usr/bin/gbr3 ", "/usr/bin/gbx3 ") & Application.Path

isn't correct, because Application.Path is a directory, not file.

And a little bug. If I use sudo method and I write good password, then
opened two window; root and error message (good with su method).


Kendek "

[vuott]

...continua...


" > isn't correct, because Application.Path is a directory, not file.

Right! You used Application.Path &/ Application.Name which seems the best
possible solution but it is yet not perfect. What if the user calls his
project A and calls the archive B.gambas? Then it would not work, right? Is
a property in Application missing?

> And a little bug. If I use sudo method and I write good password, then
> opened two window; root and error message (good with su method).

This bug was also reported to me from Hans but it never happened to me...
Let's see...

Regards,
Tobi "


" Yeah, and what if the '.gambas' filename extension doesn't exist?

But this is just an example project, users can rewrite anyway. Just see how.

Kende "