|
|
On linux systems I use a wrapper script to launch openvpn. The initial reason for doing this was that I wanted to start using the user, group and chroot options, but this wasn't compatible with my existing usage of ping-restart combined with an up/restart scripts that needed to be run as root. So I took out the daemon option, changed ping-restart to ping-exit and wrote a one-line shell script to launch openvpn then re-launch it when it died. While this approach works as far as it goes, it has limitations so I'm looking at producing a patch to add the functionality I'm after directly into openvpn. Before I do so I'd appreciate comments, suggestions or criticisms (well, polite ones anyway:-) on what I'm trying to do - particularly concerning whether or not I've missed any security implications. So, here's an overview of what I'm thinking of: The problem I'm trying to solve is that using the user, group and chroot options can cause --up (and other) scripts to fail as the openvpn process may lose permission to run the scripts (if the user or group options are used) or ability to even find the scripts (if chroot is used). The proposed patch is to add a 'fork' option (the option name is negotiable, suggestions welcome) to openvpn, which would only be effective if the 'ping-restart' option had also been given. If used, it will cause openvpn to fork at some point before any setuid/setgid/chroot calls are made. The child will get on with establishing and running the vpn (including any change of user Id's or chroots) while the parent simply waits for the child to exit. If a ping-restart occours, the child exits and the parent forks a new child to handle the restarted connection. The new child then runs appropriate scripts (should that include the 'down' script for old connection?) while it has root permissions, before changing uid's and chrooting again. To cover the various persist options, the parent will have to open tcp/udp/tun/tap handles before forking and keep them open so that subsequent children can inherit and use them. Assuming the parent never reads from or writes to the relevent file descriptors, is there any way a subverted child could use these handles to subvert it's parent? Finally, if the child exits due to an error, instead of a ping-restart, the parent should be able to recognise that from the child's exit code and react accordingly. This would be handled by the parent simply examinig the child's exit value. A last point concerning platform support. As far as I'm aware I, the extensions I'm suggesting should work with all supported platforms except windows, as windows doesn't support the user/group/chroot options in the first place. Is that correct? So, does the list consider extensions based on this proposal to be practical, desirable, pointless or downright useless and I should forget it? ---- Ewan ____________________________________________ Openvpn-users mailing list Openvpn-users@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/openvpn-users |