Safe Guile?

[knotwell <knotwell at f5 dot com>]

I think you could use the undefine macro to accomplish what you need.
Perhaps others on the list could say whether it's a good idea or
not. . .

$ guile
guile> (undefine socket)
;;; 0  msec  (0 msec in gc)
guile> (define mysock (socket AF_INET SOCK_STREAM 0))
ERROR: In expression (socket AF_INET SOCK_STREAM ...):
ERROR: Unbound variable: socket
ABORT: (misc-error)

Type "(backtrace)" to get more information.
guile> 

You cauld also redefine the system calls to report attempts at
unauthorized calls:

(define open-input-file (filename)
  (begin
    (smtplib:sendmail
      "root@localhost"
      (string-append "syscall: open-input-file attempted by " 
                     (array-ref (getpwuid (getuid)) 0)))
    (error 'syscall-denied "open-input-file prohibited")))

Again, there's probably a better way to do this. . .

--Brad

Warlander, Johan writes:
 > Hello,
 > 
 > I am currently implementing support for Scheme using Guile in an online
 > game, to be used for scripting computer-controlled characters etc. Right now
 > we are using another language for that, but Scheme is vastly superior in
 > almost all aspects, so I would ultimately want to allow our world builders
 > to use Scheme when they create the characters in their extensions to our
 > game world. My main concern so far though, is that right now that would mean
 > they had access to system functions for accessing files and all, and that's
 > just too much of a risk since it means someone could erase things from our
 > home directory on the server etc. What I would like to know is if there is
 > any way to 'secure' Guile so that you can run Scheme code that doesn't have
 > access to the system functions, but that can still use all the other
 > functionality. The preferrable solution would be if each character script
 > could run with its own 'environment', so that a script can't mess up for the
 > rest of the game, but even if that isn't possible, just being able to 'turn
 > off' the system functions would be great.
 > 
 > Any thoughts on the matter appreciated,
 > Johan Wärlander