Sandbox Violation on Runtime Exec

Michael Hall mik3hall at gmail.com
Tue Jun 12 15:20:13 PDT 2012


On Jun 12, 2012, at 3:48 PM, David DeHaven wrote:

> 
>>>> BTW, it seems Runtime.exec() uses fork() on OSX so AFAIK it may never
>>>> work in a sandbox.
>>>> The reason why NSTask works is probably because internally it uses posix_spawn.
>> 
>> In the light of this, I wonder if this behaviour should be filed as a
>> bug. There is currently no (Java only) way to create a child process
>> if the parent is executed inside a sandbox, any call to
>> Runtime.getRuntime().exec() or ProcessBuilder start() will fail.
>> I think the OpenJDK on OSX should use either posix_spawn or NSTask.
> 
> I highly recommend filing a bug, since sandboxing a Java application is something that should be fully supported.
> 

To make sure I'm understanding.
So Runtime exec is broken sandboxed period? No matter what is done with Runtime?
There would be no way to give the application a entitlement correcting the
deny file-read-data /dev/fad
as a work-around? (That would not result in the application being rejected App Store).
The long-term fix would be to change the invocation to posix_spawn which would then need no entitlement? This would be what NSTask does?

> 
> If only I'd thought of that earlier this year when I was looking at this stuff…

Curious. If the above is true. None of the jdk standard tests catch that Runtime is broken? Or the tests haven't been run yet sandboxed because that support hasn't got far enough along to be figured in for full test runs?



More information about the macosx-port-dev mailing list