Philip McGrath wrote on 08/27/2018 11:12 AM:
What I'm currently exploring, though, is writing a helper program in Racket using the FFI. It will probably read a list of paths from standard in and write a hash table to standard out mapping each path to its validation result. I still plan to run the validation in a separate process—I don't like segfaults—just the subprocess will now happen to also be implemented in Racket, communicate in s-expressions, and not have to be invoked repeatedly to track down which specific files are invalid.
That sounds like an excellent way to mitigate the C problems, when one can't yet implement in pure Racket.
For the list... If you need to compartmentalize some C code even more, there's now a few different Linux kernel access control ways to do it on a per-executable basis (SELinux, AppArmor, Tomoyo, Smack), which can be a complement to a wrapper in Racket like Philip described. Or putting it into a virtualization or container instance (or a dedicated physical server), fronted by some kind of network service in Racket. Or older Unix techniques like UID-based access control, and changing the filesystem root for the process. And making the not-entirely-trusted processes be short-lived can also help, against cumulative problems like memory leaks, and against problems that permit one invocation to affect subsequent ones.
-- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
