Re: libgnomesu [was Re: Proposed modules: my consensus so far]

[Carlos Garnacho <carlos_garnacho yahoo es>]

Hi Mark :),

 --- Mark McLoughlin <markmc redhat com> escribió: 

<snip>

> 	One thing that occurred to me when looking at
> libgnomesu was that
> usermode is no more Red Hat specific than libgnomesu
> is e.g. JDS uses
> usermode without any problems. If we find that GNOME
> has a need for this
> kind of functionality, then perhaps it makes as much
> sense for usermode
> to be included in GNOME as libgnomesu?

For me it could be worth asking why isn't it even
included optionally in some other distros, I'm taking
the Debian example, a distribution that has thousands
of packages and that hasn't still packaged this makes
me think a bit...

Dont take me wrong, I just want to be sure that we
won't make modules depend on things that distros will
refuse to package

> 
> 	Anyway, that's putting the horse in front of the
> cart a bit. What we
> really need to think about the use cases for this
> run-as-root
> functionality in GNOME and consider whether a
> libgnomesu-like
> run-this-as-root API makes more sense than a
> usermode-like
> allow-this-app-to-be-run-as-root interface.
> 
> 	So, what are the GNOME use cases? Hongli, Carlos,
> Benoît?
> 
> Cheers,
> Mark.
> 
> Comments:
> 
>   - API problems:
> 
>       + It would make sense for the APIs to
> correspond much more 
>         closely with the gspawn APIs - effectively,
> it should be
>         the same as the gspawn APIs with an added
> "user" argument.
>         See gdkspawn, for example.

As Hongli says, there are some issues that are
impossible to implement, more concretly the
child_setup stuff.

However, even knowing how hard is to implement
_with_pipes (and I know it, I've reimplemented this
part in GST some times, plus my system-auth-agent
try), I consider its lack in libgnomesu a showstopper,
as GST *needs* it for communicating with the backends

> 
>       + There's no way for multi-screen apps to
> specify which screen
>         the dialogs and the app itself should be
> displayed.

At least in the GST case, the dialog should be
placeable with gtk_window_set_transient_for(), as it's
not the first dialog that appears

> 
>       + Should have error reporting via GError

I agree

> 
>       + The "async" APIs are a bit of a misnomer
> since they block
>         until authentication has completed - why not
> make them fully
>         asynchronous by putting an IO watch on the
> pipe?
> 
>       + Users of the async APIs need to call
> waitpid() - that's messy
>         and undocumented. Why not use the
> intermediate-child technique
>         gspawn uses to avoid this? Or even better,
> use gspawn?
> 
>   - No startup-notification integration
> 
>   - Ignoring the consolehelper backend for a minute,
> isn't the PAM
>     backend sufficient? Why do we need the su
> backend? For platforms
>     that don't use PAM? If so, which platforms are
> they?

Slackware doesn't have PAM by default, but I think it
can be optionally installed. The rest of the supported
platforms have PAM by default AFAIK


<snip>

> 
>   - We've a whole copy of "su" in here. Are we going
> to keep up to date 
>     with upstream changes to the code? Copying and
> pasting code like 
>     this worries me.

I've already expressed my opinion with this too many
times, but keeping gnome tied to the good ol' console
auth methods (nor copies of them) is insane... :)

right now I can list the next desktop needs that
belong to root user:

- cpufreq changing in the new applet
- some of the GST
  - time changing
  - network
  - sharing through SMB/NFS
  - ...
- gnome log viewer
- suspending in the battstat monitor
- GDM appearance

I don't think we want to enter the root password
anytime that we want to suspend the computer and
things like this... A solution is needed, and it
should scale from systems with 1 user to multiuser
environments with non-trusted users.

      Regards



		
______________________________________________
Renovamos el Correo Yahoo!: ¡100 MB GRATIS!
Nuevos servicios, más seguridad
http://correo.yahoo.es