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

[Hongli Lai <h lai chello nl>]

Mark McLoughlin wrote:
> 	So, what are the GNOME use cases? Hongli, Carlos, Beno�

1. GNOME System Tools has a "Renice" menu item, which requires root if 
you want to give processes a lower nice value.
2. The System Log Viewer (gnome-utils) requires root access to read 
logs. I submitted a patch but nothing happened.
3. libgnomesu adds a context menu to Nautilus, which makes it possible 
to open a folder as root, so you can edit other users' files or system 
files.


>   - 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.

I tried it before. It's not possible.

I've monitored previous attempts of implementing privilege raising in 
GNOME. None of them succeeded. Basically, it boils down to:
- PAM is not available on every single OS GNOME runs on.
- Shadow passwords are, but it's unacceptable because PAM is not used on 
systems that do support it.
- Some more objections about (not) using consolehelper or other 
distro-specific authentication tools.

So obviously, writing a completely new authentication system is not the 
solution. It has been tried many times, and people never agree on it.

libgnomesu on the other hand is a wrapper around whatever whatever is 
available on the current system. It'll use consolehelper, PAM or shadow 
passwords, depending on which one is available. Because of the wrapper 
nature, I cannot provide a complex/powerful API like gspawn.

Some specific examples of problems:
- child_setup cannot be implemented. The child setup function will have 
to be called after authentication has been confirmed. This is simply not 
 possible.
- g_spawn_*_with_pipes() cannot be implemented. I can implement it using 
the modified setuid binaries in libgnomesu, but then I won't be able to 
implement ssh or sudo support in the future. Both of those programs use 
stdin (or the tty) to read the password, and to print any status 
information.

The only way to solve all this, would be to turn libgnomesu from a 
wrapper library into a full authentication system. But people won't 
agree on that, as pointed out earlier.


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

Is there a way to do that at all? If you click on an icon on your panel, 
does GNOME ask you on which screen you want to display the app?


>       + Should have error reporting via GError



>       + 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?

Not possible. The authentication dialog is part of libgnomesu. Depending 
on all kinds of stuff, the authentication dialog may not even have to 
show up! For example, if you're already root, or if you're trying to 
switch to the same user, or you're trying to switch to a user which 
doesn't have a password. In, in case of RedHat's consolehelper, if 
you've already entered your password within 5 minutes ago. There is NO 
way to tell whether an authentication dialog will show up. It all 
depends on the underlying authentication system.


>   - No startup-notification integration

Last time I checked, libstartupnotify is *still* marked as "unstable API 
which can change any time".

But anyway, even this is not possible. For startup notification to work, 
you have to set an environment variable for the child, then setup some 
kind of X property. It has to be setup before exec("authentication 
executable") is called. But what if the user entered the wrong password, 
or forgot the password, or pressed Cancel? The startup notification 
cursor will stay visible until the timeout has elasped. Very ugly.


>   - Ignoring the consolehelper backend for a minute, isn't the PAM
>     backend sufficient?

There is no make sure that RedHat's authentication tray icon appears, 
other than to directly use consolehelper. (If anybody knows how, please 
tell me.)


>  Why do we need the su backend? For platforms
>     that don't use PAM? If so, which platforms are they?

See above points. I don't know which platforms specifically, but people 
in the past have objected against using PAM as the only method in 
authentication systems. I've also heard that Linux and Solaris are the 
only systems that support PAM (not sure). I'm only keeping this backend 
around to keep people happy.


>   - The BinReloc stuff looks very dodgy to have in a library - what
>     happens if an app which links to libgnomesu also uses this stuff?

All BinReloc symbols are namespaced with "__libgnomesu_". It's very 
unlikely that any application will cause symbol clashes.


>     Unless we thought that a hack like this was the way to for GNOME
>     to address the relocatable package problem, then I think this
>     should be removed.

If you know a better solution, I'd like to hear it.

Really, we've extensively researched the relocation problem. There is NO 
clean and cross-platform solution! Unless someone convinces the POSIX 
standard group (or whatever they're called) to add an API similar to 
Win32's GetModuleFileName(), the relocation problem is here to stay.


>   - Since we run the mainloop from some of the services, won't we be
>     screwed by re-entrancy - i.e. if you click on a button that causes
>     the an app to be launcher with libgnomesu, and while the password
>     dialog is up, you click on the button again, what happens?

The dialog is modal. The user won't be able to click anything else.


>   - The thought of a Nautilus "Open as Superuser" component gives me
>     the heebie-jeebies. I'm not sure exactly why. Its irrelevant now
>     with Alex's recent changes to Nautilus, anyway :-)

Did I miss anything? What changes?


>   - 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 haven't really taken a look at the 'real' su since I copied & pasted 
it... It's a pain to get synchronized with upstream changes.


>   - su-backend/common.c:modify_environment() is a copy of usermode and
>     su code, both of which are licensed under the GPL, and you've 
>     removed the copyright notice and re-licensed to LGPL.

Hm this is a problem indeed. Maybe license the setuid executables as 
GPL, and the library as LGPL?


>   - Before executing the PAM or su backends you should more carefully
>     check that this is a "safe" directory - e.g. not writable by all -
>     and more checking of the permissions on the backend so that you
>     can be sure no-one has installed a trojan backend. Especially
>     important with the BinReloc stuff.

BinReloc can be disabled. If libgnomesu is provided as an RPM, 
relocation is not necessary.

>   - No error checking with the xauth stuff in the PAM and su backends.
>     But why not just use the same $XAUTHORITY?

Permission problems. Try switching to another non-root user.