Cannot create folder in the Program Files directory from Click-Once deployed FullTrust XBAP application

Question

Hello Everyone,

I have a problem regarding security with an XBAP application

I am writing.

This is an XBAP application that is deplyed via ClickOnce

from a web site.  The ClickOnce manifests have been signed

with a Valid Verisign certificate, and the machines CASPOL

has been configured to grant all assemblies with this

certificate the FullTrust permission set.

This works fine - I have full access to the computers

resources, I can create folders, run other programs and so

fourth - however I cannot create a folder inside the systems

"Program files" folder
System.IO.Directory.CreateDirectory(Environment.GetFolderPat

h(Environment.SpecialFolder.ProgramFiles) + "\\someFolder");

I can create folders in other places, and I think this is to

do with some kind of security sandbox that my application is

running in - even though it has the FullTrust permission

set.

This problem came about when implementing the main function

of this XBAP: to download and install an MSI.  The MSI is

downloaded successfully, and a Process is created to run

MSIEXEC and install the MSI silently.  The MSI fails with

error code 1603 (the logs state that permission was denied

when accessing the install folder, inside the program files

directory).

However, if I create the folder manually, the MSI runs

successfully, and goes on to create all the necessary exe

and dll files etc. in that folder.

This is why I am using the above "CreateFolder" code - to

allow the MSI to install - but the CreateFolder line fails with the following

security exception:

System.UnauthorizedAccessException: Access to the path 'C:\Program Files\someFolder' is denied.
   at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
   at System.IO.Directory.InternalCreateDirectory(String fullPath, String path, DirectorySecurity dirSecurity)
   at System.IO.Directory.CreateDirectory(String path, DirectorySecurity directorySecurity)

This C# XBAP is targetting framework version 3.5 SP1, and target platform x86 Running on WIndows XP Pro.  Same results verified on Vista, WinXP Home, and Vista x64.

Any help anyone could provide would be greatly appreciated.

Kind Regards,

Matthew Dendle

Answer 1

Hi Matthew,

Even your code is in "Full Trust", that doesn't mean it can bypass the Windows & NTFS security checks. From your call stack you can see that it was ultimately a WinIOError which means the access is denied by the system not the .NET runtime.

The problem here is, your account running the XBAP (IE or something else as its host) itself doesn't have the required access. And on Windows Vista or later, you also need to take UAC into consideration.

My assumption is that your MSI package is not well designed to work with UAC so it fails when trying to write to the Program Files folder.

One possible solution is to launch the msiexe.exe process elevated (Vista or later):

ProcessStartInfo psi = new ProcessStartInfo();

psi.UseShellExecute = true;
psi.Verb = "RunAs";
psi.FileName = "msiexec.exe";
psi.Arguments = "/i mypkg.msi";

Process.Start(psi);

In this way the installation should have the access to Program Files and you don't need to create the folder in your XBAP.

Another option would be running the web browser elevated (Run As Administrator), but that doesn't sound good because it could bring more risks.

Hope this helps.

Regards,
Jie
MSDN Subscriber Support in Forum
If you have any feedback on our support, please contact [e-mail]

---

Please remember to mark the replies as answers if they help and unmark them if they provide no help.

If you have any feedback, please tell us.

The CodeFx Project
My Blog (in Simplified Chinese)

Answer 2

Thanks for the reply Jie,

I'll try the RunAs verb as you suggest.

However, its exhibiting a strange behaviour - shouldnt the Process.Start() inherit the identity of its parent process?

The PresentationHost process is running as my login, and I am a member of the administrators group - and have access to the program files folder.
The process that is spawned when the Process.Start() function is called has an identity of SYSTEM.  this explains why NTFS rejects it.

Why doesnt the process inherit the identity of its caller, as I thought it would?

Kind Regards,
Matthew Dendle

Answer 3

The msiexec.exe was launched by you and it calls the Windows Installer service (running as SYSTEM, also msiexec.exe) to have the job done.

But by default, SYSTEM should have access to the Program Files folder, so I still believe the problem lies in the MSI package.

You can also try use the /L command line option of msiexec.exe and analyze the log file to see what exactly went wrong.

Regards,
Jie
MSDN Subscriber Support in Forum
If you have any feedback on our support, please contact [e-mail]

---

Please remember to mark the replies as answers if they help and unmark them if they provide no help.

If you have any feedback, please tell us.

The CodeFx Project
My Blog (in Simplified Chinese)