This didn't work for me with the following submission (in version 5.2):
#lang plai
(halt-on-errors #t)
On Sun, Jan 15, 2012 at 6:45 PM, Eli Barzilay wrote:
> 50 minutes ago, Robby Findler wrote:
>>
>> I'm not sure either (this is certainly not the only contract that's
>> checked during the exec
After going back and remembering the context, this seems like just the
right thing to me.
Robby
On Sun, Jan 15, 2012 at 8:46 PM, Matthew Flatt wrote:
> How about adding `racket/sandbox/keys':
>
> #lang racket/base
>
> (provide (protect-out suspend-file-security-key))
>
> (define suspend-file-
How about adding `racket/sandbox/keys':
#lang racket/base
(provide (protect-out suspend-file-security-key))
(define suspend-file-security-key (gensym))
;; maybe more keys for other sandbox controls
and then have "main-collects.rkt" wrap its use of
`find-executable-path' to install a mark w
(I said "mark" meaning continuation mark. FWIW.)
On Sun, Jan 15, 2012 at 7:05 PM, Eli Barzilay wrote:
> Yesterday, Robby Findler wrote:
>> Perhaps the right thing is to have the setup code export a small
>> library that contains a "is my mark bound in the context" function
>> and then the sandbox
Yesterday, Robby Findler wrote:
> Perhaps the right thing is to have the setup code export a small
> library that contains a "is my mark bound in the context" function
> and then the sandbox can call that function when deciding whether or
> not to grant permission.
>
> (That has the dependencies g
50 minutes ago, Robby Findler wrote:
>
> I'm not sure either (this is certainly not the only contract that's
> checked during the execution of PLAI programs, but maybe it's the
> only provide/contract one?), but once I disabled that, my sample
> solution for the next exercise went through.
>
> It
On Sun, Jan 15, 2012 at 5:00 PM, John Clements
wrote:
>
> On Jan 14, 2012, at 8:19 PM, Robby Findler wrote:
>
>> Perhaps the right thing is to have the setup code export a small
>> library that contains a "is my mark bound in the context" function and
>> then the sandbox can call that function whe
On Jan 14, 2012, at 8:19 PM, Robby Findler wrote:
> Perhaps the right thing is to have the setup code export a small
> library that contains a "is my mark bound in the context" function and
> then the sandbox can call that function when deciding whether or not
> to grant permission.
>
> (That ha
Perhaps the right thing is to have the setup code export a small
library that contains a "is my mark bound in the context" function and
then the sandbox can call that function when deciding whether or not
to grant permission.
(That has the dependencies going the right way, right?)
It doesn't get
Just now, Robby Findler wrote:
> On Sat, Jan 14, 2012 at 9:23 PM, Eli Barzilay wrote:
> > The sandbox shouldn't be the place for that -- it would be a
> > reversed dependency, where the setup (core) code depends on a
> > library. But in this case it's not only a "shoudln't" -- it's a
> > "cannot"
On Sat, Jan 14, 2012 at 9:23 PM, Eli Barzilay wrote:
> 20 minutes ago, Matthias Felleisen wrote:
>>
>> On Jan 14, 2012, at 9:45 PM, Eli Barzilay wrote:
>>
>> > Or maybe some private parameter (or continuation mark) that can be
>> > used to identify "I'm now in blessed code" which the sandbox
>> >
20 minutes ago, Matthias Felleisen wrote:
>
> On Jan 14, 2012, at 9:45 PM, Eli Barzilay wrote:
>
> > Or maybe some private parameter (or continuation mark) that can be
> > used to identify "I'm now in blessed code" which the sandbox
> > security guard can check and if in that case avoid the
> > r
On Sat, Jan 14, 2012 at 8:57 PM, Matthias Felleisen
wrote:
>
> On Jan 14, 2012, at 9:45 PM, Eli Barzilay wrote:
>
>> Or maybe some private
>> parameter (or continuation mark) that can be used to identify "I'm now
>> in blessed code" which the sandbox security guard can check and if in
>> that cas
The parameter solution sounds right to me and the sandbox does sound
like the right level to put that.
Robby
On Sat, Jan 14, 2012 at 8:45 PM, Eli Barzilay wrote:
> An hour ago, Robby Findler wrote:
>> On Sat, Jan 14, 2012 at 7:04 PM, Eli Barzilay wrote:
>> >
>> > Following a reply from Matthias
On Jan 14, 2012, at 9:45 PM, Eli Barzilay wrote:
> Or maybe some private
> parameter (or continuation mark) that can be used to identify "I'm now
> in blessed code" which the sandbox security guard can check and if in
> that case avoid the restrictions?
That sounds an awful lot like stack inspe
An hour ago, Robby Findler wrote:
> On Sat, Jan 14, 2012 at 7:04 PM, Eli Barzilay wrote:
> >
> > Following a reply from Matthias, I tried it in drr, and that does
> > have an offending exists, but looking at the stacktrace, there's a
> > `print-values' so it sounds like the drr-installed printer -
When I set up the modules below, I get these two stacktraces for what
seem to be thinks the sandbox would reject:
[robby@yanpu] ~$ racket ~/tmp.rkt
security guard: current-directory # (exists)
(#f . #(struct:srcloc # 9 17 283 475))
(find-main-collects . #(struct:srcloc
#
19 4 817 884))
(#f .
On Sat, Jan 14, 2012 at 7:04 PM, Eli Barzilay wrote:
> 20 minutes ago, Eli Barzilay wrote:
>>
>> But regardless, when I run it (properly) I see:
>>
>> security guard: current-directory #f (exists)
>
> Following a reply from Matthias, I tried it in drr, and that does have
> an offending exists, b
20 minutes ago, Eli Barzilay wrote:
>
> But regardless, when I run it (properly) I see:
>
> security guard: current-directory #f (exists)
Following a reply from Matthias, I tried it in drr, and that does have
an offending exists, but looking at the stacktrace, there's a
`print-values' so it so
10 minutes ago, Robby Findler wrote:
> This is the correct example.
>
> #lang racket/base
> (define ns (make-base-namespace))
I was about to say that I don't see any output with this, but I
missed the above -- so if you use the module's namespace via an anchor
there is no printout. This means th
This is the correct example.
#lang racket/base
(define ns (make-base-namespace))
(parameterize ([current-namespace ns]
[current-security-guard
(make-security-guard
(current-security-guard)
(λ (name path what)
(whe
10 minutes ago, Robby Findler wrote:
> Does variable-reference->module-source use current-directory?
>
> If so, that'd explain this. (And either it would have to change or
> the handin-server/sandbox would have to.)
It looks like it does -- running the code below shows
>>> (find-system-path #
Does variable-reference->module-source use current-directory?
If so, that'd explain this. (And either it would have to change or the
handin-server/sandbox would have to.)
Robby
On Sat, Jan 14, 2012 at 4:28 PM, Eli Barzilay wrote:
> 40 minutes ago, Robby Findler wrote:
>> While we wait for Eli t
40 minutes ago, Robby Findler wrote:
> While we wait for Eli to either fix the bug or to track this down to
> some other part of the system,
It's not a handin server or a sandbox bug -- it's a problem of some
code that tries to get `exists' access to some directories, which is
usually harmless sin
While we wait for Eli to either fix the bug or to track this down to
some other part of the system, applying this diff makes the problem go
away for me.
diff --git a/collects/plai/test-harness.rkt b/collects/plai/test-harness.rkt
index a3f9575..923ea4e 100644
--- a/collects/plai/test-harness.rkt
+
Was this ever resolved? I see the same thing and it is a problem for my class.
I'll reiterate what John said: calling this function seems to be the
issue; the handin server works fine otherwise. Here's the
implementation of this function, which seems pretty innocuous.
(provide/contract (print-onl
Four hours ago, John Clements wrote:
> I'm having a problem using PLAI plus the handin server.
> Specifically, it looks like using (print-only-errors #t) in my code
> triggers the error
>
> submit error: Error in your code --
> current-directory: `exists' access denied for /home/clements/class/han
27 matches
Mail list logo
