[Xmonad] darcs patch: fix potential hole in userCode.

[David Roundy]

On Fri, Oct 12, 2007 at 10:32:48AM -0700, Don Stewart wrote:
> droundy:
> > Oe Fri, Oct 12, 2007 at 10:11:13AM -0500, Spencer Janssen wrote:
> > > On Friday 12 October 2007 10:03:52 David Roundy wrote:
> > > > Fri Oct 12 11:02:53 EDT 2007  David Roundy <droundy at darcs.net>
> > > >   * fix potential hole in userCode.
> > > >   This makes userCode catch errors even when the
> > > >   user does something like (return undefined).
> > > 
> > > Applied.
> > 
> > I was thinking that we might get a little more benefit from adding just a
> > tad of strictness to catchX itself.  It could call seq on the return value
> > to catch at least the grossest errors that might be hidden in lazy values.
> > That still wouldn't obsolete this change to userCode, since the advantage
> > when we've got a () return value is that we can safely ignore it and keep
> > any changes that might have been made.
> 
> Fwiw, here's the exception catching code from lambdabot. This has to
> evaluate completely untrusted code, of course:
> 
>     case s of
>         Left  e -> mapM_ putStrLn e
>         Right v -> Control.Exception.catch
>             (putStrLn v)
>             (\e -> Control.Exception.handle (const $ putStrLn "Exception") $ do
>                         e' <- Control.Exception.evaluate e
>                         putStrLn $ "Exception: " ++ take 1024 (show e'))
> 
> Right means there was no compile error. So we then show the value, forcing it.
> Note that it can throw an exception whose thrown value is an exception.
> 'evaluate' takes care of some of the work for us.

That's interesting.  Although Config can be assumed to be less hostile than
lambdabot users, we've got a slightly harder problem in catchX, since we
know of no way to force the value (as showing it does for lambdabot).

Probably worrying about calls to (error (error "Gotcha!")) is beyond the
scope of catchX, as we don't need to deal with malicious code, just buggy
code, and I can't imagine how someone would accidentally do something like
that.  Malicious people, of course, will just write bug-free code that
deletes the user's home directory, which catchX can't prevent.

Of course, if IO were broken up into smaller monads, we could restrict code
to not touch the filesystem if we wanted.  Or even better, if we had a
really tricky monad, code could be restricted to only touch the
~/.xmonadcontrib/ directory...  :)
-- 
David Roundy
Department of Physics
Oregon State University