[Gambas-user] Relaunching a program as root

[Bruce]

On Sun, 2013-12-29 at 21:59 +0100, Tobias Boege wrote:
> 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
> 
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:
        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:

  ' 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

p.s. The "last straw that breaks the camel's back" might not be what you
wanted.  It conveys a complaint from the recipient of a task to the
sender as in when I am going to the shops for a 5 minute visit and
someone says "Oh, while you're there can you get me..." and someone else
says "Could you also drop by the baker and get me some ..." and someone
else says "Can you check if there is any mail at the post office".  At
that point my "load of straw", i.e. the task load, just got too heavy.
In Australian, I reply, "Well, that's about the last bloody straw".

Here, we have a saying "Yes, somebody ought to do something about that"
that is used when a problem is mentioned for the thousandth time.
Inevitably, some poor sod will take a deep breath and undertake to fix
the said problem, thinking "and I suppose that "somebody" will have to
be me". Is that what you meant?