On Tue, 5 Oct 2004, Mathias Sundman wrote: > So to summarize: > > SW=Service Wrapper > > 1. The SW should redirect stdin/stdout/stderr through a pipe. > > 2. The SW will write everything arriving on stdout/stderr to a logfile. > > 3. The SW will monitor stdout/stderr for password prompts, and when it > sees one it will send a query over the already established TCP session to > the GUI, which will respond with the password. The SW then passes this > back to openvpn over the pipe.
I agree that only one TCP connection between GUI and SW is appropriate, even when the SW is controlling multiple openvpn processes. > Is there any security issues with this we need to consider? I think there should be some sort of admin password which the SW will expect before it grants access to a GUI process connecting as a TCP client on the SW's local socket. > 4. The GUI will have to monitor the accual log file on disk in order to be > able to show the log in real-time. For this to work, it's important that > the SW flushes its write buffer to disk after every write. > > Which is the best way of writing to a file, and making sure it's really > written to disk, on Windows? > > WriteFile(), fprintf(), fputs(), write()? If you're using a FILE *, fflush() is usually sufficient. I believe if you use native Win32 I/O such as WriteFile, the flush is immediate (not to say it physically goes to disk but rather that it is immediately available to another process which reads it.) Another point: Portability. It would be nice to make a portable SW that would work on all the platforms that OpenVPN runs on. James > > On Tue, 5 Oct 2004, Didier Conchaudron wrote: > > > Hi all, > > > > I agree with James for including several things such as monitoring > > stdin/out/err into the wrapper. > > > > But I'm not very ok for the idea of creating a socket for each connection > > because our users will probably only use one GUI so this GUI may have to > > discuss throught a unique socket to make things simpler. Now I agree that > > they're problems when we run several tunnels. I think of a system where > > each > > starting tunnel can ask, throught the same socket, a password or user/pass > > data just by adding a header like: > > > > foo.ovpn: asking private key password > > foo2.ovpn: asking extended auth. username > > > > This way the GUI will have to handle just one socket, it could be then > > simpler to add features to GUI, ITOA it's harder for wrapper to add those. > > > > An other point is security. Actually the service wrapper need to run as > > SYSTEM/Admin rights, we have to limit the features and commands which will > > run as SYSTEM. > > > > Didier > > > > James Yonan wrote: > >> On Fri, 1 Oct 2004, Mathias Sundman wrote: > >> > >> > >>> Didier announced a first release of an improved version of the OpenVPN > >>> Service Wrapper earlier this week. The goal with this is to allow a non > >>> admin user on Windows to start/stop openvpn processes. > >>> > >>> It does this by listening on a local TCP socket for commands like "START > >>> config.ovpn" or "STOP config.ovpn". > >>> > >>> I've started working on OpenVPN GUI 2.0 that will use this service > >>> wrapper to control openvpn. > >>> > >>> There is two things that remain unsolved though that I'd like to bring > >>> up for some discussion. > >>> > >>> 1. How do we pass the private key passphrase from the GUI to the openvpn > >>> process? > >>> > >>> 2. How do we get the openvpn log to the GUI so we can show it in real > >>> time in the status window? > >>> > >>> > >>> I can see a couple of solutions: > >>> > >>> A) We create a pipe between the openvpn process and the service wrapper. > >>> The service can then watch the openvpn output for the passphrase prompt, > >>> and pass on the request to the GUI over the TCP socket. > >>> > >>> The log is then written to the log file by the service. The GUI will > >>> have to monitor this file for changes to be able to show the log in > >>> real-time. > >>> > >>> > >>> B) We create another TCP socket for every launched process, and creates > >>> a pipe between this socket and the openvpn process. The GUI can then > >>> connect to this socket to recieve the log in real-time, and can monitor > >>> this for the passphrase prompt itself. > >> > >> > >> I like the idea of having the service wrapper control the > >> stdin/stdout/stderr which is passed to the openvpn process, then have it > >> send password(s) over stdin. > >> > >> So the communication between the service wrapper and the openvpn processes > >> would be via standard i/o handles and the communication between the > >> service wrapper and the GUI would be over the management socket. > >> > >> That means the service wrapper would need to be a proxy of sorts, passing > >> passwords and possibly log file output as well between the GUI and openvpn > >> processes. > >> > >> James > > > ------------------------------------------------------- > This SF.net email is sponsored by: IT Product Guide on ITManagersJournal > Use IT products in your business? Tell us what you think of them. Give us > Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more > http://productguide.itmanagersjournal.com/guidepromo.tmpl > _______________________________________________ > Openvpn-devel mailing list > Openvpn-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/openvpn-devel >
