Hi,
Lev, unfortunately, the openvpn.exe binary will still contain this hack's machine code and might really rise some eyebrows with anti-virus software. Before the final release the entire SYSTEM token hack should be removed from the OpenVPN source. I think it's okay to make a note in README that "--windows-driver wintun" works with iservice only. (Or, if user is responsible to run openvpn.exe as SYSTEM user himself somehow.) Regards, Simon From: Lev Stipakov <lstipa...@gmail.com> Sent: Tuesday, December 17, 2019 10:35 AM To: Selva Nair <selva.n...@gmail.com> Cc: Simon Rozman <si...@rozman.si>; Lev Stipakov <l...@openvpn.net>; openvpn-devel <openvpn-devel@lists.sourceforge.net> Subject: Re: [Openvpn-devel] [PATCH v6 4/7] wintun: ring buffers based I/O How about compromise - let's add "--enable-system-elevation" windows specific option. - When it is set, we print warning and elevate to SYSTEM for the single DeviceIOControl call - When it is not set and wintun is used, we run openvpn from command line via iservice - If service is missing, we print error "either use iservice or --enable-system-elevation (experts only)" The ones who want to run openvpn from command line with wintun still could do it via psexec and it is assumed that they know what they are doing. So why not make it simpler and add a option "yes I know what I am doing and I am willing to take risks"? Also, it is safer to use system privilege just for single call rather than run whole process with it. This also will make debugging / development easier.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
