Re: c++ -> guile threading

[Greg Harvey <Greg.Harvey@thezone.net>]

Peter Amstutz <tetron@student.umass.edu> writes:

> 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

It's a bit contorted, which is why a new environment representation
was proposed ;). A sample of fetching all the available symbols in a
module can be found in the apropos code in the session module. 

Basically, what you want is something like:

(define-module (user-code-module))

(define eval #f)
(define load #f)
...

And all user code would be run in the user-code-module.

My thinking is that with a more flexible system of environments, there
will probably be support at the guile level for safe vs. full bindings
(it is, in fact, possible right now, it just hasn't been done
yet). You could totally blank things out doing:

(set-module-uses! (current-module) '())

But then you get nothing at all, which isn't very useful ;)

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

Well, not that exhaustive ;)... it's true, though, that this would be
a very limited and iffy way of providing protection (I was only
thinking of checking for usage of illegal functions, not verifying that the
thing actually stops ;).

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

And eval, macros & quasiquotes, I would think.

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

I'd think that this should work (I think the only thread stuff that
goes on is directly triggered by guile, without the use of
signals... I don't know for a fact, though; hopefully someone else can
fill in that gap).

-- 
Greg