So secure I can’t use it – Oracle ODP and Windows 7 User Access Control

No more Windows XP for Mark.  I say that with at least a tear of sorrow – XP was a champion operating system for me for over 7 years.

As of a couple of weeks ago, my primary workstation at Biggs was replaced, and that meant moving from Windows XP to Windows 7.  I won’t go into all of the details as to why I was still using Windows XP in 2011, but a large part of it has to do with the issues I’m going to describe here.

This issues really center around two things – the Oracle Data Provider (ODP) and Windows User Access Control (UAC).

SELECT * FROM Grrr
The issues with ODP started right at the beginning, with the installer itself.  When I build an application that will go against Oracle, I have to use the Oracle 10.2 client (since that’s what the customer is using).  When I first tried to run the installer for the 10.2 client, it died saying that it would only support through Windows version 6.  So, I had to set the compatibility to Windows XP SP3 (right click on the .exe and go to properties, then go to the Compatibility tab).

That got me past the initial check, but the install failed later in the process.  I then tried restarting the installer as an Administrator (still with Windows XP compatibility enabled).  It got further this time, but not quite to the end. 

The installer was now failing at the 98% mark because it was trying to register some files using C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin\Gacutil.exe.  That folder existed on my machine, but not that file.  How nice that the developer who put the Oracle installer together didn’t include something that could register things with the GAC, and furthermore assumed that I would have VS 2005 (aka Visual Studio 8 ) on my machine?  I checked my home machine (which had Visual Studio 2005 on it at one point) and found that I had that file, so I copied Gacutil.exe and Gacutil.exe.config from my home machine to my work machine.  This time, the installer finished successfully.  (I considered looking for Gacutil.exe elsewhere on my machine and just copying it into the expected folder, but since this worked I didn’t bother going down that route.)  Yay for me.

When I tried to use ODP, however (e.g., running a site in Debug mode on my machine, or running a test through NUnit that hit the database), it failed with a very generic Oracle error (something to the effect of "Oracle error has occurred").  Through trial and error, I found if I ran THOSE applications as an Administrator, the connections to Oracle would work fine.

Let me be clear.  I wasn’t trying to run Oracle locally – I was trying to connect to our development Oracle instance from my workstation.  How were the connections to our development SQL Server instance working?  Yeah, those worked fine on my machine whether I ran Visual Studio and NUnit as an Administrator or not.

How about PL/SQL Developer?  Couldn’t connect to Oracle unless it was run as an Administrator.

How about SQL Server Management Studio?  Worked fine as Administrator or not.

Grrr

My domain account is an administrator of my local machine, but apparently that isn’t enough.  I found that if I completely disabled UAC, however, these would run correctly.  I was really tempted to just disable UAC altogether – which does work, by the way – but I really wanted to find a way to work within the system, which boiled down to running Visual Studio, NUnit, and PL/SQL Developer as an Administrator, every time. 

Why is nothing ever easy?
Running these apps as Administrator was a bit of a pain, however, mostly because I kept forgetting that I needed to do it.  So, I set out to try to smooth out the process of launching applications under UAC.

I religiously use an application launcher called SlickRun.  I hit Windows-Q to bring up the SlickRun command line, type in a customized keyword, or "MagicWord", for the application, site, or command I want to run, and hit Enter.  So, for example, to bring up PL/SQL Developer I would hit Windows-Q, type in "oracle", and hit Enter.

SlickRun has an option that can be checked per MagicWord called "Prompt for user-account (aka elevate to admin)".  I turned that on for PL/SQL Developer, so when I started it up it would throw up the UAC prompt.  Once I hit "Yes" (or Shift-Tab then Space to click the "Yes" button without my fingers leaving the keyboard) PL/SQL Developer would open as an Administrator.  I did the same thing for Textpad and NUnit.

My next challenge was Visual Studio.  The normal way I open a solution in VS is to browse to the .sln file on my file system and double-click it.

For that, I tried marking the Visual Studio executable to always run as Administrator:

• Right click on C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe
• Select Properties
• Click on the Compatibility tab
• Click "Run this program as an administrator"

Once I did that, however, double-clicking the SLN file did nothing.

Then I remembered that SLN files are set to open with the Visual Studio Version Selector, which reads the SLN file and opens it in the correct version of Visual Studio.  I found that executable (C:\Program Files\Common Files\microsoft shared\MSEnv\VSLauncher.exe), and tried the same "Run this program as an Administrator" trick.  That didn’t work.  According to this StackOverflow article, that WOULD have worked prior to SP1 being installed: http://stackoverflow.com/questions/3304425/visual-studio-version-selector-doesnt-open.  After SP1, you have to hack the VSLauncher.exe manifest:

• Back up VSLauncher.exe and VSLauncher.exe.manifest
• Run VS Command Prompt as an Administrator
• Switch into the C:\Program Files\Common Files\microsoft shared\MSEnv folder
• Run this command:  mt -inputresource:"VSLauncher.exe" -out:VSLauncher.exe.manifest
• Alter the VSLauncher.exe.manifest file, specifically the "level" attribute of the requestedExecutionLevel tag:

                    <requestedPrivileges>
                        <requestedExecutionLevel level="requireAdministrator" uiAccess="false">
                        </requestedExecutionLevel>
                    </requestedPrivileges>

• Run this command:  mt -outputresource:VSLauncher.exe -manifest VSLauncher.exe.manifest

That allows the Launcher to run as an Administrator, so it can now launch Devenv.exe as an Administrator.

<rant>
Why in the world is any of this necessary?  Why are local admin rights not sufficient for running a site against Oracle on my local machine?  Alternatively, do connections to SQL Server from my local machine require similarly inflated privileges, but because it’s a Microsoft data connector on a Microsoft operating system, it just works more smoothly?
</rant>

Even after all of this, though, I don’t regret moving to Windows 7.  There are a lot of things I like about it, but there needs to be some additional grey matter applied to the concept of application security.

Advertisement