On 23 Feb 2015, at 09:54, Peter Zotov <[email protected]> wrote: > > Roberto Di Cosmo wrote: >> What I do not know is whether something similar is available for *BSD, and >> even less for Windows. > > I have spent an extended amount of time on this issue in OS X. > Plain and simple, it is not possible to intercept syscalls on XNU. > The ptrace API does not implement PTRACE_SYSCALL, and the equivalent > Mach API, task_set_emulation, has not ever been implemented. > I've looked into the XNU sources too and there is simply no codepath > that performs what you need. > > Forget about this kind of user-space sandboxing on OS X.
The other issue with ptrace-based sandboxing is just how slow it is due to all the context switching that's imposed. I don't think it would fly for day-to-day use. > However, OS X provides an explicit sandboxing mechanism since 10.5. > I don't think it will work for opam either: > > The app sandbox container directory has the following characteristics: > It is located at a system-defined path, within the user’s home directory. > The container is in a hidden location, and so users do not interact with it > directly. > > (from > https://developer.apple.com/library/mac/documentation/Security/Conceptual/AppSandboxDesignGuide/AppSandboxInDepth/AppSandboxInDepth.html#//apple_ref/doc/uid/TP40011183-CH3-SW6) I think this could be made to work, but it all depends on how viable it is to sign the opam binary with the right entitlements. If anyone who has a Mac App store account can experiment with this with a toy binary and report back, that would be most useful... Maybe we should rewrite OPAM in Swift, Louis? :-) -anil _______________________________________________ opam-devel mailing list [email protected] http://lists.ocaml.org/listinfo/opam-devel
