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 [email protected]. For more options, visit https://groups.google.com/d/optout.
