Re: c++ -> guile threading

[Peter Amstutz <tetron@student.umass.edu>]

On Sat, 8 May 1999, Greg Harvey wrote:

> > > This is sort of a large, drooling security hole.
> > 
> > This brings up a seperate question then:  how do I start up a "blank"
> > guile system - one with a nearly bare environment that's just keywords
> > (define, let, if, lambda, etc...) so I can just allow in library calls
> > (both my own and some standard scheme) deemed to be safe?
> 
> What you could do, is run the user code in a module that redefines all
> the stuff that you don't want them to access. It's currently not the
> nicest solution; I think this is something that should be looked at

Actually it just occured to me the simple way out would be to 
(define dangerous_function #f) for all the calls that look a bit
dangerous...  Is there a way to get a listing of all the functions defined
in the current environment?  Also, is there a way to disable loading the
ice-9 set of library calls at guile boot time?

> once the environment stuff is implemented (and just in case I'm
> correctly anticipating your next question, I have no idea when that'll
> be ;) Jost Boekemeier has done some work on this, but I haven't had

What sort of model does guile use for bindings if not for an environment
model?  A nice BLANK environment is all I'm asking for...   Hell, we just
wrote a small scheme system IN scheme in one of my comp sci classes, maybe
I should go use that instead on top of guile :P

> the time to sit down with his code yet). You could also scan through
> their code to make sure they aren't using anything funky, but that's
> probably a bit too dangerous, since you could always miss something.

Heh, yea, all I have to do is solve the Turing halting problem first :)
(actually I have a computer science professor trying to automate solving
halting proofs for ML programs in MetaML, but that obviously doesn't help
me :)


I basically want to clobber all functions involving the file system,
networking, or console I/O.  Really anything that creates side effects
outside the guile sandbox.  Then I can define my own very restricted
functions for talking to the outside world...

> Yeah, there's definately not anything close to ready for prime time
> with os threads yet.

Bugger.
 
> > > You should be able to do this with asyncs (see async.c in the libguile
> > > directory). The source file contains some documentation on how to use
> > > them, and instructions on how to use them from unix signal handlers (I
> > > have partial written documentation on this, but there are a few bits I
> > > still need to figure out, so it's not available yet).
> > 
> > It's pretty vague...  A bit of example code showing what/how this
> > works would be quite enlightening :)
> 
> Wouldn't it, tho? ;) Thinking a bit more about it (like, about how
> much I should've thought first), it's probably just as well to use
> guile's own threads (or go with your idea), since you'd essentially be
> reimplementing threads this way (I wasn't thinking about resuming the
> user code when I wrote that... it's easy if you just chuck it after
> their time is up >;'), but that probably wouldn't be a really great
> idea).

Yea, what I'm _considering_ right now is using pthreads in my C++ code and
then running guile in a single thread, and using guile threads within that
system.  Seems a bit tricky (I really have to learn more about guile
threading first) but possible if they don't conflict on any basic level
(like, I think pthreads uses SIGUSR1 and SIGUSR2, I hope QuickThreads
doesn't).  I don't _want_ to clobber people who do dumb things and upload
infinite-loop code, I'm just trying to plug an obvious DoS hole.

           ------------------ Peter Amstutz --------------------
           -------------- tetron@student.umass.edu -------------
           ------- http://www-unix.oit.umass.edu/~tetron -------
           -----------------------------------------------------