Hi Alon, 2012/5/11 Alon Bar-Lev <alon.bar...@gmail.com>: > On Fri, May 11, 2012 at 12:11 AM, Fabian Knittel > <fabian.knit...@lettink.de> wrote: >> 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!
To be honest, I'm not sure what you're talking about. My point was, that the ideas and approaches gathered in the wiki[0] might influence the interface we're discussing right now. Specifically, Heiko's interactive service would probably need a similar interface. (In your COM+-approach this would be the interface between OpenVPNUI.Network and OpenVPNUI.Tunnel, but as you're suggesting to use COM+, the shape of an advanced management interface or unix-domain-socket-like interface is ... of no real value.) 0: https://community.openvpn.net/openvpn/wiki/PrivilegeSeparation > And again, these UI specific issues should should be modularize and > not go into mainline as-is. My point was, that we should agree on a stable interface first. In the next step, we can decide whether a specific implementation of that interface is worthy of inclusion. Unless of course, you're thinking about COM+ as one of the UI interfaces. But in my opinion, if Windows has a communication channel that is close to the semantics and capabilities of a UNIX domain socket, we should probably use that as _the_ interface and not needlessly start maintaining a separate interface per UI/plattform. [...] > 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. I agree that your question is more to the point. My opinion regarding the question is, that I don't yet see a need for a library interface. Executable + unix domain sockets seem just fine. >> * 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 create a contract that can be upheld by both a plugin and the core, then we can agree on the contract first and agree or change the implementation of the contract later. If we take several UI needs into consideration, we might not need a zoo of management-UI-plugins. > If we provide tun engine implementation that supports the management > interface, all platforms can benefit from this change. Sounds great. Why not make the management interface contract of that tun engine the main topic of this discussion? That's what I'm aiming at. That way, hopefully the short-term patch can go in and the contract won't need to change as soon as 2.4 delivers the advanced modularisation. Cheers Fabian
