BorlandTalk.com

Clayton Arends · Guest

I have encountered a problem on Vista with one of my company's applications.
Internet Explorer seems to be "sandboxing" an ActiveX control that we've
written denying it the ability to create files in the OS. Has anyone else
seen this behavior and know of how to work around it?

Here is a complete description.

Background:

A user will connect via a web browser to launch one of our client
applications. The web page has an embedded ActiveX control (an Active Form)
that is served by the web server via a signed CAB. We call this ActiveX app
our "Universal Client Launcher". The param tags on the web page inform the
launcher of what client needs to be run.

When the launcher opens it connects to a server to check for the current
installed version of a client. If the current version doesn't exist on the
user's machine it is downloaded and extracted to the user's application data
directory. Then the client is launched. In our current implementation the
clients are all Win32 EXE applications.

What works:

This scenario has been working flawlessly with XP (2000 and Win98 worked
with an earlier version of this scenario but we haven't tested it recently).
For systems where the users have limited privileges (ie, they can't install
ActiveX controls) the system admin needs to install the launcher for them.
From that point the user can get the latest versions of our clients as they
become available. And because the launcher rarely changes the system admin
is hardly ever involved in the process after the initial install.

The problem:

With Vista the administrator is able to install our ActiveX launcher without
problem. The administrator can also install and launch any one of our
client applications. A user can also launch our ActiveX launcher. The
problem happens when the client is extracted and executed. The OS claims
that the files exist on the user's system. However, checking the
appropriate directories the files do not exist. When the launcher opens the
application, ShellExecute() returns an error code of 5
(SE_ERR_ACCESSDENIED).

Sample code:

Following is a modified version of the launcher. I have provided enough
code here to show the logic flow and the main functions that we use.

String prodPath = ConstructFileName(GetSpecialFolder(CSIDL_APPDATA),
"OurCompany\\" + ApplicationName + "\\" + Version);

if (!DirectoryExists(prodPath)) // (A)
{
// Create the directory to place the files
if (!ForceDirectories(prodPath))
throw Exception("Couldn't create path: " + prodPath);

// Download and extract the files to 'prodPath'
// ... internal stuff
}

// Determine the EXE name to run
String exeName = // ... internal stuff

if (!FileExists(exeName)) // (B)
throw Exception("EXE doesn't exist: " + exeName);

int res = reinterpret_cast <int> (::ShellExecute(NULL, NULL,
exeName.c_str(), parameters.c_str(), prodPath.c_str(),
SW_SHOWNORMAL));
if (res <= 32)
{
RaiseLastOSError();
}

ConstructFileName() is a function that correctly appends argument two to the
end of argument one for use as a folder or file name. GetSpecialFolder() is
a function that makes calls to SHGetSpecialFolderLocation(), etc to retrieve
the full path to a special system folder. On my XP development machine
'prodPath' contains:

c:\Documents and Settings\username\Application Data\
OurCompany\appname\version

On our test Vista machine 'prodPath' contains:

c:\Users\username\AppData\Roaming\OurCompany\appname\version

The first time the launcher runs the 'prodPath' doesn't exist. The line
marked (A) evaluates to true. This results in the files being downloaded
and extracted into 'prodPath'. At line (B) the file check evaluates to
false (meaning the file exists) and ShellExecute() is called returning 5.
RaiseLastOSError() throws the following exception:

System Error. Code: 5.
Access is denied.

If I run the launcher again this time when it reaches (A) the evaluation
results in false (the directory does exist). The files are not extracted
again. Line (B) results in false again and ShellExecute() produces the same
result. A quick peek at the file system shows that the directory
"c:\Users\username\AppData\Roaming\OurCompany" does not exist and therefore
neither do any of the sub directories or files.

What else I've tried:

I created a test application that loads the ActiveX control. This
application represents the part that IE would be playing. The ActiveX
launches, retrieves the files, and runs the client just fine. So, it would
seem that the ActiveX control running in IE has limited permissions or the
operations are somehow being "sandboxed".

Has anyone encountered a situation such as this with Vista yet and know of
any solution?

BCB6 Pro
- Clayton

Clayton Arends · Guest

First, sorry for posting in b.p.c.nativeapi. Perhaps the question would
have been better asked in b.p.c.activex.

Second, as I investigated the issue more I found the new "Enable protected
mode" checkbox in IE's "Tools | Options | Security" dialog. This option was
hiding in plain sight so you can understand why I didn't see it before Wink

.
By unchecking this check box my launcher is now able to successfully
retrieve, write, and launch the client applications. However, now IE
complains that the user is surfing "unprotected".

I looked for an option to selectively allow certain trusted ActiveX controls
to run "unprotected" but couldn't find such an option. If somebody knows of
an option like that or any other solution to this problem I would be
grateful.

- Clayton

Clayton Arends · Guest

The solution we seem to be leaning toward is to have our customers place the
website that serves the OCX in their "Trusted Sites" zone. This works and
doesn't nag the user when they are navigating the site unprotected.

What I have been investigating is how to make the OCX become a "broker shim"
(I think that's how to say it). This way whenever it's launched by a user
account the OCX will be able to have medium access rights and write to the
user's appdata directory. My initial tests of this method have not been
successful. Using the admin account I added a key to:

HKLM\SOFTWARE\Microsoft\Internet Explorer\Low Rights\ElevationPolicy

The key was named with the CLSID of my ActiveX control and I added the
following two values:

CLSID [REG_SZ] = my activex control's CLSID
Policy [REG_DWORD] = 2

This will probably be the final post I have in this thread unless I get this
working (or someone else gives their 2 cents).

- Clayton