On Fri, May 11, 2012 at 12:11 AM, Fabian Knittel <fabian.knit...@lettink.de> wrote: > Hi, > > 2012/5/10 David Sommerseth <openvpn.l...@topphemmelig.net>: >> On 10/05/12 16:50, Alon Bar-Lev wrote: >>> Why? plugin is adding a custom logic, and you need custom logic. As >>> I wrote it does not imply that you implement your JNI there. >> >> Okay ... fine ... there are plenty of big visions for a future version >> of OpenVPN, and it will become more modular, yes. I think we all >> agree there. >> >> What is far more important now is the review the *current* patch, this >> review process have so far derailed completely. Lets put this current >> discussion aside. Later on we will discuss this how to modularise >> OpenVPN anyway. > > To allow OpenVPN to be properly refactored afterwards, the important > part is probably to get the external interfaces correct (which never > works in practice, but it would be nice to get close...). > > The main undecided points regarding the interface side of things appear to be: > * How to pass the fds back and forth: Special-case the management > interface for unix domain sockets or use a dedicated unix domain > socket for special operations. Could this potentially be the same > interface that was discussed for some of the windows privilege > separation approaches?
Again, this is not the case of privileged separation as the process *IS* privileged to do the networking setup. People, don't get confused between running under root or not with privileges! Regular user can have privileges like creating tun and modify network setting without being root, as in this case, this is not privilege separation! And again, these UI specific issues should should be modularize and not go into mainline as-is. > * How to call OpenVPN from Java. Via thin JNI wrapper or as a regular > executable. Again, this is not the question. The question is do we want to make a library out of VPN with some interface such as openvpn_main() or not, the JNI question is totally unrelated to the mainline project. > * The precise names of the newly introduced management commands. If we provide plugin interface to management interface this can be a contract between the UI and the plugin, so that mainline should not be changed every time there is a special UI need. If we provide tun engine implementation that supports the management interface, all platforms can benefit from this change. > > Anything else? > > Cheers > Fabian
