[racket] Limiting net-repl provided functions

Great, thanks again! It will take a while to digest and try this out in
practise.

br, jukka


> -----Original Message-----
> From: samth0 at gmail.com [mailto:samth0 at gmail.com]On Behalf Of Sam
> Tobin-Hochstadt
> Sent: 27 June 2011 17:40
> To: Jukka Tuominen
> Cc: users at racket-lang.org
> Subject: Re: [racket] Limiting net-repl provided functions
>
>
> On Mon, Jun 27, 2011 at 10:08 AM, Jukka Tuominen
> <jukka.tuominen at finndesign.fi> wrote:
> >
> > So, once I hopefully have it working locally, how do I apply it into the
> > net-repl server? I think the following is the correct definition to be
> > tweaked (non-modified from net-repl). Do I add the
> sandbox-environment to
> > evals or something?
> >
> >  (define net-repl-eval
> >    (let ([eval (current-eval)])
>
> You'll want to construct a sandboxed evaluator here, perhaps using
> `current-eval'.  But more likely, you don't need `current-eval' at
> all.  To create a sandbox, do something like this:
>
> (require racket/sandbox)
> (make-evaluator 'racket/base)
>
> That produces a procedure that works like `eval', but in a new sandbox
> that only has access to `racket/base'.
>
> >      (lambda (exit)
> >        (lambda (expr)
> >          (if (equal?
> >               (if (syntax? expr)
> >                   (syntax-object->datum expr)
> >                   expr)
> >               '(#%top-interaction close))
> >              (exit)
> >              (eval expr))))))
> >
> >
> > br, jukka
> >
> >
> >> -----Original Message-----
> >> From: samth0 at gmail.com [mailto:samth0 at gmail.com]On Behalf Of Sam
> >> Tobin-Hochstadt
> >> Sent: 27 June 2011 16:53
> >> To: Jukka Tuominen
> >> Cc: users at racket-lang.org
> >> Subject: Re: [racket] Limiting net-repl provided functions
> >>
> >>
> >> On Mon, Jun 27, 2011 at 9:48 AM, Jukka Tuominen
> >> <jukka.tuominen at finndesign.fi> wrote:
> >> > BTW, 'secure' in this context may mean allowing even critical
> >> system calls
> >> > (say format harddisk), if so specified. But the user should not
> >> be able to
> >> > do anything else than specified.
> >>
> >> The `sandbox' infrastructure is fairly flexible.  Just by constructing
> >> a namespace and doing the `eval' in that namespace, you'll be able to
> >> restrict which identifiers the remote user can refer to.  If those are
> >> very limited, that might be enough for security.
> >>
> >> >> -----Original Message-----
> >> >> From: samth0 at gmail.com [mailto:samth0 at gmail.com]On Behalf Of Sam
> >> >> Tobin-Hochstadt
> >> >> Sent: 27 June 2011 16:10
> >> >> To: Jukka Tuominen
> >> >> Cc: users at racket-lang.org
> >> >> Subject: Re: [racket] Limiting net-repl provided functions
> >> >>
> >> >>
> >> >> On Mon, Jun 27, 2011 at 8:48 AM, Jukka Tuominen
> >> >> <jukka.tuominen at finndesign.fi> wrote:
> >> >> >
> >> >> > The basic client/server functionality is already working, but
> >> >> it's too big a
> >> >> > security risk outside LAN use. It seems to be easier to add
> >> >> functionality
> >> >> > than ripping them off. Perhaps creating a custom #%top
> definition to
> >> >> > interfere with the default symbol lookup...?
> >> >>
> >> >> The right place to look is at sandboxes:
> >> >>   http://docs.racket-lang.org/reference/Sandboxed_Evaluation.html
> >> >> and namespaces:
> >> >>   http://docs.racket-lang.org/guide/mk-namespace.html
> >> >>
> >> >> --
> >> >> sam th
> >> >> samth at ccs.neu.edu
> >> >
> >> > _________________________________________________
> >> >  For list-related administrative tasks:
> >> >  http://lists.racket-lang.org/listinfo/users
> >> >
> >>
> >>
> >>
> >> --
> >> sam th
> >> samth at ccs.neu.edu
> >
> > _________________________________________________
> >  For list-related administrative tasks:
> >  http://lists.racket-lang.org/listinfo/users
> >
>
>
>
> --
> sam th
> samth at ccs.neu.edu