2

I think I have a security issue here but can't seem to get around it. I am running IIS 7.5 with an application pool named "MyAppPool." I am then calling a program from C# code, PDFCreator.exe, which reads from C:\DWF and then writes C:\DWF\DWF.PDF.

I have given IIS AppPool\MyAppPool full rights to PDFCreator.exe as well as the C:\DWF directory. When C# creates the process and calls PDFCreator.exe, it simply starts a process showing MyAppPool as owner but never opens the application.

Can anyone chime in on anything security-related I may be missing?

ProcessStartInfo processStartInfo = new ProcessStartInfo(@"c:\program files (x86)\pdfcreator\pdfcreator.exe");
processStartInfo.Arguments = @"/PF""c:\dwf\dwf.dwf"" /NoStart";
processStartInfo.RedirectStandardInput = true;
processStartInfo.RedirectStandardOutput = true;
processStartInfo.RedirectStandardError = true;
processStartInfo.UseShellExecute = false;
Process process = Process.Start(processStartInfo);
// Read the output stream first and then wait
string output = process.StandardOutput.ReadToEnd();
string errors = process.StandardError.ReadToEnd();
Response.Write(output + errors);
Ben Pilbrow
  • 12,041
  • 5
  • 36
  • 57
SteveCalPoly
  • 23
  • 1
  • 4
  • If you do `Process.Start(@"c:\program files (x86)\pdfcreator\pdfcreator.exe",@"/PF""c:\dwf\dwf.dwf"" /NoStart")` does it work? Are you sure it's a permissions serverfault problem? – user Jan 26 '12 at 18:12
  • Running that starts a process in the task manager owned by "MyAppPool" but the application window doesn't open and complete it's task as if i ran that same command via desktop shortcut with target parameters (which works). – SteveCalPoly Jan 26 '12 at 18:15
  • @SteveCalPoly The application will not open a window that you can see, processes run from IIS (or any other system service) do not have access to the desktop and therefore you can never see any windows they open. That's why there is a checkbox on the `Log On` tab of windows services that explicitly give services that permission. Does your application (`pdfcreator.exe`) require the ability to interact with the desktop? – Coding Gorilla Jan 26 '12 at 18:34
  • Yes, it's kind of crafty actually. What happens is, pdfcreator opens another application called AutoDesk Design Review. This app then prints to a PDF file using PDFCreator's printer driver and saves it to the desktop. Hopefully this is configurable to allow design review to open and do it's thing. – SteveCalPoly Jan 26 '12 at 18:38
  • Gah, I see where to configure it in the services.msc panel. What if this PDFCreator.exe service is not there? – SteveCalPoly Jan 26 '12 at 19:00

1 Answers1

1

That's a suboptimal design for an IIS application.

Desktop apps run interactively.

IIS apps run as a service - without displaying a user interface to the user.

You're essentially using IIS to kick off some background processing tasks (because there's no GUI visible to you) that think they're foreground processing tasks.

The "kind of crafty" bit you mentioned in your comments is exactly why you might have problems doing this. Just to pick one sentence:

"This app then prints to a PDF file using PDFCreator's printer driver and saves it to the desktop."

In the case of an IIS AppPool user, where's the desktop?

You could try using a specific user account (not an IIS AppPool\ThisIsAVirtualAccount virtual App Pool Identity account) which gives it a specific profile, and setting Load User Profile to True (App Pool properties) in order to ensure the profile folders (and the printer driver) are available for that user.

But this is all stuff that's going to be happening somewhere in the background on an IIS box, and if the app decides to pop an error dialog, that's it, it's broken until the box restarts. Like I said, suboptimal.

TristanK
  • 9,073
  • 2
  • 28
  • 39
  • 1
    I misspoke when i said the file will be saved to the desktop, it actually gets saved to a specified directory that has already been configured within the app being called. The app opens, prints, saves that file to specified directory and closes itself in a matter of about 3-4 seconds. If it breaks I am not sure what would happen since it isn't running all the time, but rather it is constantly reopening and closing itself. I suppose the more bulletproof solution is to find an app that can do 100% of this work at the command line without ever opening. Thank you for your feedback. – SteveCalPoly Jan 27 '12 at 00:56
  • The second part may still work - use a progressively-greater-permissioned specific user as the App Pool account (assuming the work is happening as them and isn't in any way authenticated) to nut out whether it's permissions or just sheer unworkability of the apps. – TristanK Jan 27 '12 at 01:53
  • 1
    Was able to get it to work with myself as the user in the app pool. It works quite effectively and never opens itself to the desktop. Next step is for me to talk to our server team and see what account they're ok with using to do this. This web app will only be accessible to our intranet. – SteveCalPoly Feb 01 '12 at 19:32