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

[Mark McLoughlin <markmc redhat com>]

Hi Honglai,

On Wed, 2004-11-24 at 13:50 +0100, Hongli Lai wrote:
> 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.

	I think (2) is certainly sensible. It is the typical
graphical-sysadmin-tool just like gnome-system-tools, Fedora system
tools etc.

	(1) worries me because it leaks some admin-tool functionality into a
user tool which I think is likely to be frustrating and confusing for
users who *don't* have root. It also isn't optimal for users who *do*
have root - having to type the root password for every process you want
to kill isn't fun.

	Being able to access other users files in (3) is interesting, but just
starting nautilus as the other user sounds like it would be confusing.
How do you know which window is yours and which window is the other
users? Can you drag and drop between windows? If I was looking to allow
another user to access my files, I'd expect it to work by "Share Folder"
rather than typing in my password for them.

	But anyway, the reason I was asking about use cases was to figure out
whether we need a libgnomesu-like "launch this app as root" API or a
usermode-like "this app needs to be run as root" install time interface.
I'd prefer to err on the side of the latter if we're unsure.

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

	Okay, I can see that shadow password support is neccessary now.

> - Some more objections about (not) using consolehelper or other 
> distro-specific authentication tools.

	There's nothing (apart from the lack of shadow password support)
distribution specific about usermode/consolehelper really.

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

	Right, I'm sorry. You obviously couldn't implement full g_spawn()
functionality - the point I was trying to make is that the API should
*look* like a g_spawn() API for consistency. Nothing more.

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

	If you have multiple screens the panel will start the app on the screen
which you click the launcher using the gdk_spawn() API. Essentially, the
libgnomesu() API should be able to take a GdkScreen argument.

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

	I'm not sure I understand. Why does the caller need to know whether an
authentication dialog was displayed?

	As an example, the PAM service could do the following:

  1) g_spawn_async_with_pipes() the PAM backend
  2) Put a watch on the stdout pipe and return to the caller
  3) When there's input on the stdout pipe, process it
  4) If the child asks for a password, display a dialog
  5) When you get a response (asynchronously) from the dialog,
     return write that on the backend helper's stdin pipe

> >   - No startup-notification integration
> 
> Last time I checked, libstartupnotify is *still* marked as "unstable API 
> which can change any time".

	Yes, but if libgnomesu was part of the Desktop Release, it would be
perfectly valid for it to use the API.

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

	It requires some communication between the backend and the launching
process. See how usermode does it, for example. One thing that I notice
usermode doesn't do is handle launchee failures, but that shouldn't be
hard to do.

	Its important, though, that if the support was added we only do it for
apps which we know supports it. So, you'd have a "startup_notify" flag
in the API which the panel would set depending on the StartupNotify flag
in the .desktop file.

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

	Sure, sure - I was ignoring usermode/consolehelper because I don't
think it really makes sense for usermode to exist if we use libgnomesu.

	But, yeah, you do need multiple backends - you need to support shadow
passwords. Could do that in the same backend binary, though, right?

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

	Okay, hadn't noticed that.

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

	Right, we haven't figured out a good way to fix this. But it would
strike me as pointless for one small part of GNOME to try and fix it
independantly of the rest of GNOME - especially when the hack is going
to make security concious people very nervous.

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

	I don't see where the password dialog is being made modal ..

	Anyway, I'm not sure that relying on the dialog being modal is good
enough to protect against re-entrancy. What happens if you're launching
from an idle handler or timeout?

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

	No bonobo components for Nautilus anymore.

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

	Right, that's my point ... shouldn't we be worried about that ? :-)

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

	That would work, but don't forget to restore the copyright notices.

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

	Ah :-)

Thanks,
Mark.