This is the mail archive of the
mailing list for the Guile project.
Re: c++ -> guile threading
- To: Greg Harvey <Greg.Harvey@thezone.net>
- Subject: Re: c++ -> guile threading
- From: Peter Amstutz <email@example.com>
- Date: Sat, 8 May 1999 15:38:22 -0400 (EDT)
- cc: firstname.lastname@example.org
- Reply-To: email@example.com
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
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.
> > > 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
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 --------------------
-------------- firstname.lastname@example.org -------------
------- http://www-unix.oit.umass.edu/~tetron -------