[Gambas-user] Access global variable from other .class

[Benoît Minisini]

Le 16/06/2012 03:44, Bruce a écrit :
> On Sat, 2012-06-16 at 01:17 +0300, Jussi Lahtinen wrote:
>> OK, got it.
>> It's now "fixed" (actually xfce function was missing), tested and attached.
>>
>> Benoit, is this official part of xdg-utils..? Because I have that package
>> installed, but not that script.
>>
>> Jussi
>>
> Jussi,
>
> No, xdg-su is no longer part of xdg-utils.  There is a whole lot of
> ***xdg-su and xdg-su*** scripts in the wild, some are xdg compliant,
> some are not so.
>
> AFAIK the last portland release was 1.1.0 about a year or more ago.
> Even that had some signs of "wear-and-tear" in that the release notes
> and readme files seem fairly out of date.
>
> I had some problems last year using gb.desktop on an LXDE system that
> resulted in me looking very deeply into the xdg situation.  At that time
> pcman (the LXDE originator) had spent considerable effort getting LXDE
> recognised by the scripts.  What I could not understand then was how
> things "just worked" when I ran the xdg-utils from a terminal and just
> didn't when invoked through gb.desktop.  I then found that gambas is
> using an internal set of these utilities.  So these need to be
> maintained!  (As you have just done with the xdg-su script.)
>
> I have not used the xdg-su script for privilege escalation, but a quick
> (and I mean quick!) look through it at it stands is not going to be a
> great success.
>
> Which gets me back to your
>> "Weird that there isn't any standard about this, or is there..?
>> I think every linux distribution should have link to it's graphical
>> version of sudo/su, with uniform name like GUIsudo.
>> Then you could always call it without knowing which environment is
>> used."
>
> The fact is, there isn't and one of the major reasons is the old ongoing
> su/sudo argument and how certain distros implement their own policies
> regarding this.  (I don't intend on pursuing that argument further here)
>
> So, the following is a set of comments on the various utilities around
> now:
>
> GKSU/GKSUDO
> Pro: Easy to use, can handle complex command strings*, easy to configure
> the authorisation gui to suit
> Con: There are some security issues, the major one to me is that it
> escalates the current user's privilege, not the current process.  Even
> more of an issue is that the escalation actually remains in force for a
> period of time after the gksu command is finished.
> Also, there is currently some talk in gnome circles (fairy rings?) that
> gksu will be replaced.
>
> KDESU/KDESUDO
> Pro: Easy to use, can handle complex command strings.
> Con: Some security issues, authorisation gui is not configurable.
>
> PKEXE
> Pro: Presumeably desktop agnostic but actually restricted to distros the
> implement policykit.
> Con: Can only handle single commands.  Creates a session running as root
> with the working directory set to /root rather than escalating current
> user or process privileges (some may see this as a Pro, I disagree.)
> Also the authorisation gui is not configurable and it displays more
> information than some may like (like the real path of the command that
> is going to be executed.)
> It also cannot run gui commands.
>
> xdg-su
> Pro: Integrated with Gambas through gb.desktop
> Con: Supported desktops! Needs maintenance within gambas!
> Unknown: What does it actually escalate?  A quick look at several of the
> versions around indicate that many rely on su?
>
> * a complex command string being something like
> 'cd /home/blah/blah;echo pwd; make install; echo "Success!"'
>
> One final comment, GKSU, KDESU and PKEXE all run happily on my LXDE box
> and perform "correctly" (i.e. within the constraints expressed above).
> But on my CentOS test box, only pkexe works.  :-(
>
> Bruce
>

Maybe it would be possible to write a graphical su entirely in Gambas? 
The first difficulty I see is how to know if we must use 'su' or 'sudo' 
to run the command...

-- 
Benoît Minisini