How to isolate untrusted native code in Java?

Question

I have a part of the C library that I don’t trust (in the sense that it can often crash). I am calling this from a Java process.

To avoid a crash in the C library that brings the entire Java application. I thought it would be better if I create dedicated java processes for this library and let it interact with a Java application. via socket programming or RMI. Then, if a failure occurs, I can simply create another one and continue processing.

Is there a ProcessBuilder way? Or are there other easier ways?

Thanks!

Answer 1

Yes, placing native code in a separate Java process is the only way to protect your application from native code.

As for simpler methods, there are just minor differences in implementation. For example, without creating code from your Java application and wrapping your own code in your own shell, which is configured to run automatically. This will simplify the solution if you have knowledge of C and sockets. In this approach, RMI would not be the best choice.

Even if you put your own code in Java, I still haven't chosen RMI. I ran into network problems with Windows on a WAN. I would make communication as easy as possible. If the data is too complex, perhaps this is the basic serialization library. If you are following an XML route, there are several options. This is redundant, but you can also implement a http server and web services. I do not know your system requirements, bu

Recovery will create many problems. If it stops responding, you simply create another process ... how many times you want to do it ... Process control with Java leaves much to be desired.

Answer 2

I do not know an easier way.

For the interaction between the parent and the child, I did not use RMI or sockets - I would use the child standard input and output streams available through the Process object. It is simple, efficient and confidential. You can use streams in the same way as socket streams, although without any considerations of identification, addresses, authentication, etc. You can write the protocol yourself or use something like Thrift or protocol buffers to create a protocol from entity definitions.

Answer 3

If performance is not a problem, and if there is a chance that other applications will fall into your "native" service, I would choose RESTful or some other kind of web service. As for re-emergence in accidents, as others have noted, just create the process as a service, and you should be good to go.

If your application is the only entity that will hit this own service, then I would prefer to go the RMI path rather than the pure socket path. IMO, RMI is a natural approach to interprocess communication (where processes are Java processes). RMI has the concept of an "activated" remote object, which would be a natural approach, taking into account your requirements (auto-spawn in case of an accident). In addition, if you use RMI, your application will talk to its own process through well-defined Java interfaces, and not to contract contracts (which can be achieved using other high-level solutions, such as web services, but a real pain when it comes to talking about raw sockets).

BTW, JFTR, we use this strategy with our production application, and it works pretty well, YMMV. :-)