This is the mail archive of the guile@cygnus.com mailing list for the guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Another use for Guile/Scheme/Lisp


ttn@netcom.com writes:

> Redford, John writes:
> 
>  > [ref to language "Obliq"]
>  >
>  > You're right about the ease with which Scheme code can be transported and
>  > executed elsewhere (or elsewhen). The main problem I see when doing these
>  > things is the security model. There needs to be a clean way to write an
>  > 'eval' loop that does not have risky procedures available (like
>  > 'open-file'). Additionally having a way to impose quotas on an eval to
>  > prevent a bit of code from running too long would be good to have. There
>  > needs to be more to the model than "You have a certificate, so I'll trust
>  > you entirely." What comes after that is Scheme as a "web language".
> 
> one way:
> 
> (use-modules (ice-9 session) (ice-9 common-list))
> 
> (define safe-eval-procs
>   (set-difference (apropos-internal ".*")
>                   '(open-file eval eval-safely other-dangerous-stuff)))
> 
> (define (eval-safely form)
>   (and form (car form)
>        (if (assq (car form) safe-eval-procs)
>            (eval form)
>            (formatted-error "Unsafe proc `%s', ignoring." (car form)))))

This is not at all safe.  In fact, it is pretty naive.

> another way is to create a local environment via module system, etc.

I don't think that the Java way of ebforcing security is the right
way.  The traditional way of providing security is by given processes
some `user identity' and then deciding at the lowest level of the OS
whether that process os allowed to do something or not.  These
mechanisms should be used by all security related things on the
system.

When some remote server wants to execute some code on your system,
that server has to log in just like any other user.