Add "RequestExecutionLevel admin" to tapinstall.exe manifest file

[Samuli Seppänen]

Currently standalone tapinstall.exe does not automatically raise privileges on Windows Vista/7 as it should. This should be trivial to fix by modifying it's manifest file.

[Samuli Seppänen]

This can probably done post-build with mt.exe:

• ​https://msdn.microsoft.com/en-us/library/ms235591.aspx

[Samuli Seppänen]

A simple manifest along the lines of ​https://github.com/OpenVPN/openvpn-gui/blob/master/res/openvpn-gui.manifest should do the trick.

[Samuli Seppänen]

This is a bit more tricky than I imagined. Building devcon.exe (tapinstall.exe) using the tap-windows6 buildsystem does not work properly, so I am using a special tapinstall.exe executables from jamesyonan, and adding the resources during devcon/tapinstall build is not an option. On top of that mt.exe seems to be missing from Visual Studio 2012 and 2014.

D12fk suggested using a generic Windows resource editor, which probably is the sanest strategy here. The only trick is to find a trustworthy one.

[Samuli Seppänen]

Discussed this in today's community meeting, and agreed that this is not a blocker for 2.4.0. We decided to try an external manifest file first, and if that fails, try embedding the manifest into the executable itself.

[Selva Nair]

Try the following as an external manifest file: name it as tapinstall.exe.manifest
and copy to same folder as tapinstall.exe

EDIT: Tested on Server 2008 and Win7 (an irrelevant section removed from the manifest)

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1"
    manifestVersion="1.0">
<assemblyIdentity
    name="TapInstall.Manifest"
    version="1.0.0.0"
    type="win32"/>
<description>Tap driver install</description>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
    <security>
        <requestedPrivileges>
            <requestedExecutionLevel
                level="requireAdministrator"
                uiAccess="false"/>
        </requestedPrivileges>
    </security>
</trustInfo>
</assembly>

[Selva Nair]

@samuli: I tested the external manifest approach and it works fine. I've seen reports that adding an external manifest to an already installed executable sometimes fails to work unless the time stamp of the executable not updated --- something equivalent to touch file like

Set-ItemProperty tapinstall.exe LastWriteTime (Get-Date)

should do it. But it worked for me without any such hacks.

With this manifest in place, both addtap.bat and tapinstall.exe raised UAC prompts. tapinstalll was reported as "Windows Setup API published by OpenVPN ..."

If possible let's distribute the manifest with the Tap Windows installer and have it copied to the same location as tapinstall.exe. Else we can include in openvpn installer and have it copied to the right place..

[Samuli Seppänen]

I can put the manifest file into the tap-windows6 installer. OpenVPN 2.4_rc1 is too close (today/early tomorrow) so this will have to wait until rc2.

[Samuli Seppänen]

@selvanair: I tested the manifest file on Windows 7 and Windows 2012r2. In both cases it was necessary to do

Set-ItemProperty tapinstall.exe LastWriteTime (Get-Date)

Without that fix tapinstall.exe would ignore the manifest file completely.

There were some inconsistencies in how Windows was able to use the manifest, though. Take this command sequence for example:

cd 'c:\Program Files\Tap-Windows\bin'
.\tapinstall.exe install .\driver\OemVista.inf tap0901

The results were mixed:

Application	Launched as admin?	Shows UAC?	Result
cmd.exe	No	Yes	Command completes successfully
cmd.exe	Yes	No	Command completes successfully
powershell	No	No	tapinstall.exe shows its internal help and quits
powershell	Yes	No	Command completes successfully

I don't think the non-admin Powershell issue is related to the manifest file itself.

I will issue a PR that will include the manifest file. In that PR I will look into how to fix the tapinstall.exe write timestamp on the fly.

[Samuli Seppänen]

Pull request ​here.

[Samuli Seppänen]

Fixed in slightly different fashion by tap-windows6 ​PR#23, which just got merged. Once an updated installer is available this ticket can be closed.

[Samuli Seppänen]

The new snapshot installers should contain PR#23, so this can now be closed. The 2.4.1 installers will also have the fix.