[racket] Question about sandbox.rktl failing its unit test

[Tim Brown]

Folks,

I've just built racket-5.3.5 on Solaris-11 Intel (32 and 64 bit flavours).
Because I need to embed Racket into C, as well as run it standalone, I have
also built both the CGC (Boehm) and 3m (default) versions.

So that's four versions of racket. All of which seem to run with stability.

However, I have run the `all.rkt` test suite on all four, and it bails out
in sandbox.rkt with:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
$ /usr/local/racket-master/SunOS-5.11-amd64/bin/racketcgc -f
/usr/local/racket-master/SunOS-5.11-amd64/lib/racket/collects/tests/racket/sandbox.rktl
[successful sandbox tests ending in...]
(#<procedure:run> #<procedure:...ket/sandbox.rktl:75:55>) ==> (exn:
#(struct:exn:fail:contract "bytes-length: contract violation\n expected:
bytes?\n given: #f" #<continuation-mark-set>))
BUT EXPECTED (vals: 400000)
#t
[then about 10 further tests]
(#<procedure:run*> #<procedure:...ket/sandbox.rktl:73:55>) ==>
(#<procedure:run*> #<procedure:...ket/sandbox.rktl:73:55>) ==> (exn:
#(struct:exn:fail "current-load-relative-directory: `exists' access denied
for
/usr/local/racket-master/SunOS-5.11-amd64/lib/racket/collects/tests/racket/" #<continuation-mark-set>))
BUT EXPECTED #t
(#<procedure:e-match?> "terminated .thread-killed.$" #<procedure:run>
#<procedure:...ket/sandbox.rktl:76:55>) ==> #t
...
[snip]
...
[finishing in]
current-load-relative-directory: `exists' access denied for
/usr/local/racket-master/SunOS-5.11-amd64/lib/racket/collects/tests/racket/
context...:

/usr2/local/racket-master/SunOS-5.11-amd64/lib/racket/collects/racket/sandbox.rkt:611:0:
evaluate-program

/usr2/local/racket-master/SunOS-5.11-amd64/lib/racket/collects/racket/private/more-scheme.rkt:146:2:
call-with-break-parameterization

/usr2/local/racket-master/SunOS-5.11-amd64/lib/racket/collects/racket/sandbox.rkt:744:2:
user-process
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

It turns out that /usr/local is a symlink to /usr2/local (and therefore
/usr/local/racket... is physically located on /usr2/local/racket...).

The final exception is not one that is handled as an exception in the test
suite.

There are a number of questions raised:
* is this failure, in sandbox checking `exists', an intended behaviour
when the file in question is a symbolic link (or descendent)?
* if not, is this a Solaris file system issue (does this problem not
manifest itself on Linux)?
* should the final exception be caught?
And therefore increase the number of failed tests/exceptions?
And allow the test suite to progress.

If someone could tell me how they would expect a symlink in a sandbox
to be handled, and if Solaris is not behaving as expected I'll take a look
at it.

Cheers,

Tim
--
Tim Brown <tim.brown at cityc.co.uk> | City Computing Limited |
T: [phone] | City House, Sutton Park Road |
F: [phone] | Sutton, Surrey, SM1 2AE, GB |
-----------------------------------------------------------------------|
BEAUTY: What's in your eye when you have a bee in your hand |
-----------------------------------------------------------------------'
City Computing Limited registered in London No. 1767817.
Registered Office: City House, Sutton Park Road, Sutton, Surrey, SM1 2AE
VAT number 372 8290 34.

[Tim Brown]

Have you tried the current HEAD? There were some changes in the handling
of symlinks on *nix platforms after 5.3.5 that might fix this.

Thanks for getting back to me.

I'll try that... I haven't looked much further into this, since I didn't
know whether sandboxes don't play nice with symlinks on purpose. Apache
HTTPD, for example, looks upon them with deep suspicion.

Is there any merit to this kind of paranoia when it comes to racket?

Tim
--
Tim Brown <tim.brown at cityc.co.uk> | City Computing Limited |
T: [phone] | City House, Sutton Park Road |
F: [phone] | Sutton, Surrey, SM1 2AE, GB |
-----------------------------------------------------------------------|
BEAUTY: What's in your eye when you have a bee in your hand |
-----------------------------------------------------------------------'
City Computing Limited registered in London No. 1767817.
Registered Office: City House, Sutton Park Road, Sutton, Surrey, SM1 2AE
VAT number 372 8290 34.

[Sam Tobin-Hochstadt]

I believe this was not related to symbolic links, and has now been fixed.

Sam

Post by Tim Brown

Have you tried the current HEAD? There were some changes in the handling
of symlinks on *nix platforms after 5.3.5 that might fix this.

Thanks for getting back to me.
I'll try that... I haven't looked much further into this, since I didn't
know whether sandboxes don't play nice with symlinks on purpose. Apache
HTTPD, for example, looks upon them with deep suspicion.
Is there any merit to this kind of paranoia when it comes to racket?
Tim
--
Tim Brown <tim.brown at cityc.co.uk> | City Computing Limited |
T: [phone] | City House, Sutton Park Road |
F: [phone] | Sutton, Surrey, SM1 2AE, GB |
------------------------------**------------------------------**
-----------|
BEAUTY: What's in your eye when you have a bee in your hand |
------------------------------**------------------------------**
-----------'
City Computing Limited registered in London No. 1767817.
Registered Office: City House, Sutton Park Road, Sutton, Surrey, SM1 2AE
VAT number 372 8290 34.
____________________
http://lists.racket-lang.org/**users <http://lists.racket-lang.org/users>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20130704/4363ddcd/attachment.html>