Re: network-manager-iodine

[Dan Williams <dcbw redhat com>]

On Sun, 2012-02-26 at 18:40 +0100, Guido Günther wrote:
> Hi Dan,
> On Fri, Feb 24, 2012 at 02:25:49PM -0600, Dan Williams wrote:
> > On Thu, 2012-02-09 at 13:49 +0100, Guido Günther wrote:
> > > Hi
> > > I've written a small network-manager VPN plugin that uses iodine to
> > > tunnel through DNS which can be usefull in case you're behind a firewall
> > > but DNS queries are allowed:
> > > 
> > > 	https://honk.sigxcpu.org/piki/projects/network-manager-iodine/
> > > 	git clone git://honk.sigxcpu.org/git/network-manager-iodine.git
> > > 
> > > There are auth and property dialogs and we run chrooted and unprivilged
> > > by default. I wonder if this is suitable to be moved over to
> > > git.gnome.org alongside with the other modules.
> > 
> > Very nice; also quite clean.  Though I wonder if iodine couldn't be
> > patched to accept the password over stdin instead of the environment?
> 
> It turned out that this is already possible so I changed the code to use
> stdin. Thanks for having a look!
> 
> > In any case, it appears that only the program's user can
> > read /proc/<pid>/environ so we're probably safe there, but environment
> > inheritance is fraught with danger.  I could be wrong, but if iodine
> > spawns a process later, and forgets to clear the environment, it might
> > leak the password through to that child process.  But anyway...  Yeah,
> > this is suitable to be moved to git.gnome.org.  I think you've got a git
> > account now; want to request a git repo and push it?
> 
> Done, thanks. I have one question though. What's the correct way to
> return errors from the plugin to NetworkManger from functions that run
> when real_connect has already finished? Like iodine_stderr_cb?

Plugins use the "failure" signal to indicate that, using libnm-glib that
would be:

nm_vpn_plugin_failure (NM_VPN_PLUGIN (plugin),
NM_VPN_PLUGIN_FAILURE_CONNECT_FAILED);

with the correct error code.  The current error codes aren't very
detailed, but if there's one we need we can certainly add it.  And in
reality, we should be adding a more detailed error signal that also
takes a descriptive string with more information that can be logged by
NM or passed up to the user.  That's not hard to implement, just a
parallel signal to Failure that has a "us" dbus signature.

Dan