[saagarjha]

> IOW: code using sandboxing "printf" would have to be changed to use "_sanbdoxed_printf" somehow (via code or linker tricks).

I mean, linker tricks à la LD_PRELOAD, DYLD_INSERT_LIBRARIES are a lot less work than rewriting code. They don't even require a recompile most of the time.

I think this does however bring up an interesting point: it seems like this library is trying to solve a somewhat different subset of the sandboxing, which is the question of "how do I maintain separation if I'm writing code on both sides of the sandbox", whereas sandboxing can also include "how do I stop this arbitrary binary from doing malicious things". It seems to me that the latter usually ends up requiring support in the kernel or linker but no cooperation from the sandboxed process itself, while the former requires adoption new API (for example, macOS's XPC).

[jagger11]

Hi,

> I mean, linker tricks à la LD_PRELOAD, DYLD_INSERT_LIBRARIES are a lot less work than rewriting code. They don't even require a recompile most of the time.

Thanks. Also, simply providing static symbols during compilation should work (in most cases), as typically a static linker will only pick up the first provided and referenced (yet undefined) symbol.

Probably even a more "stable" (less conflicting) solution would be to use -Wl,--wrap=symbol and then provide __wrap_symbol() sandboxed definition. Agree, this all doable one way or another, and we might take a look at it at some point (we'll be glad to receive any input on that, preferably on the project's mailing list).

[saagarjha]

Would that be [e-mail]?