Re: GNOME System Monitor will use libgnomesu

[Hongli Lai <h lai chello nl>]

Mark McLoughlin wrote:
> On Sat, 2005-01-08 at 15:06 +0100, Hongli Lai wrote:

> 	Okay, let me repeat everything I said in the previous thread. And let
> me be clear that these are "objections" to the adoption of
> libgnomesu ... although, how you could claim to not think these were
> objections first time around is beyond me ...

Let me clarify: with "objections" I meant "strong objections that MUST 
be dealed with, or libgnomesu will destroy the universe".
Certainly there are criticism, but they're not huge/blocker issues, and 
they can be fixed in the future. libgnomesu will be part of the desktop 
platform, not developer platform.

I've already answered many of the criticisms. I will do it again.


>    - libgnomesu is a "launch this program as root" API - I think that's 
>      the wrong form for this functionality to take and an install time 
>      "this app needs to be run as root" interface is more appropriate
>      (e.g. like usermode)

And that's why libgnomesu uses usermode/consolehelper whenever it can!
But let's face it:
- usermode/consolehelper, although said to be distribution-independend, 
is only available in a hand ful of distributions! People will never 
agree on using usermode for every application. Especially when you have 
to consider that GNOME must also run on non-Linux platforms.
- People have been talking about this issue for YEARS, and the situation 
STILL hasn't changed. Something must be done.

Sure, libgnomesu is not perfect. But it's still better than not having 
anything at all. There's nothing preventing anybody to write something 
better than libgnomesu.


>    - I worry that the addition libgnomesu-like API to the desktop will 
>      lead to the UI being littered (in unpredictable places) with root 
>      password dialogs e.g.
>
>        - "Open as root" in Nautilus context menus
>        - "Run as root" in the run dialog
>        - Random features in apps asking for root like the "renice" and
>          "kill" features in gnome-system-monitor
>
>      What a horrible thought.

See Mike Hearn's email.
And having root password dialogs popping up is better than telling the 
user to open a terminal and type 'su -c foobar'.


>  Specific objections about the API/implementation:
>
>    - APIs should correspond to the gspawn() APIs where possible

As I said in previous emails, it's technically impossible to provide 
features like pipes. Unless certain system programs are modified.

My first attempt was to mimmic the GSpawn API. But it failed. Then I 
took a good look at the API and realized that it's just overly 
complicated, so I replaced the API calls with simpler calls instead.


>    - multi-screen apps need a way to specify which screen to
>      launch the program on
>
>    - should have error reporting via GError
>
>    - "async" APIs which block
>
>    - users of async APIs need to call waitpid()

Many applications don't need complex stuff like that. I was praised by 
several application authors for providing a simple API. And there's 
nothing that prevents me from adding a more complex API later, for the 
apps that need it.


>    - No startup-notification

On TODO list.


>    - BinReloc stuff is silly to just have in one GNOME module - its an 
>      issue which cannot be addressed one module at a time

It's disabled by default.


>    - Re-entrancy issues

You could say the same thing about gtk_dialog_run().


>    - Issue about maintainability of an entire copy of "su"

It's technically impossible use the system's su, unless I dramatically 
cut down libgnomesu's feature set.

If I have to use the system's su, then I must write an entire terminal 
emulator. I know from experience that many Linux distributions' su 
behave in a slightly different way when it comes to reading the password 
from the terminal. Imagine how messy the code would look like if I have 
to deal with all the other Unix systems too!


>    - licensing issues - some of the code is (c) Red Hat, Inc., but the
>      Copyright notice appears to have been removed

Already fixed a while ago.


>    - No checking for EINTR from waitpid()

I'll add this to the TODO list.
What does EINTR mean? I don't understand the what the waitpid manpage is 
talking about.