3

This is code from a class library:

proc.StartInfo = new ProcessStartInfo(CmdPath, "+an -b");
proc.StartInfo.RedirectStandardOutput = true;
proc.StartInfo.CreateNoWindow = true;
proc.StartInfo.UseShellExecute = false;
proc.Start();
proc.WaitForExit();

This works perfectly as I would expect when called from a console test app. When I take the same library and call the method from an ASP .NET web service it just hangs.

Is there something I am missing here, perhaps permissions? The ASPNET service has access to the folder where the EXE is, and I see it running in Task Manager, though it isn't doing anything.

If anyone could tell me what I'm doing wrong, I would appreciate it. Thanks.

EDIT: Sorry for the lack of information. CmdPath goes to the command line interface for our scheduling software. I'm passing in commands based on the documentation they provided. I have one method to get a list of jobs, and another method to run a job. ...hmm idea. The client normally uses Active Directory to login, I think impersonation is going to be necessary. Going to test now.

EDIT 2: Ok, now the client is blowing up with AccessViolation issues. This is obviously a permissions thing. If the software uses integrated AD authorization, and I impersonate my AD account, will that be sufficient? I'm doing impersonation using the tag in web.config.

IronicMuffin
  • 4,182
  • 12
  • 47
  • 90
  • You don't specify what CmdPath does - if it is asking for user input, it's going to sit there for a looong time! Try using Process Explorer to see what's actually running in that external process. – Jeremy McGee Dec 04 '09 at 14:32
  • For your Edit2: Typically for situations like this I have seen folks impersonate an Identity only for the call that needs this access, obviously all your windows identities provided by callers will not have access on your server, so ideally you will want to impersonate only for the call to invoke your exe instead of impersonation at the web.config level - see this: http://blogs.msdn.com/shawnfa/archive/2005/03/21/400088.aspx - Run without impersonation - use impersonation only for the code block where you launch your process and then go back to normal. – Ta01 Dec 04 '09 at 14:52
  • @bnkdev: I quickly implemented this and tried calling the library using INTERACTIVE. Still getting AccessViolation errors. At this point, it may be the program I am trying to call. Are there gotchas for using the impersonated token to authenticate with AD? – IronicMuffin Dec 04 '09 at 15:12
  • @bnkdev: That took me right back to round one - just hangs indefinitely. Process only takes a couple of seconds normally. – IronicMuffin Dec 04 '09 at 15:47
  • Alright, let me take a look at some code one of the dev's here wrote internally, I'm 99% sure he was doing exactly what you are doing, although we all advised him against it, he had no recourse. – Ta01 Dec 04 '09 at 17:50
  • Much appreciated. I would have done this directly with the API, but it is outdated and doesn't work either (and is being completely dropped next version). My guess is that the software doesn't like impersonation for some reason since it is so tightly integrated with AD. Their support didn't have much to say about it, either, so I'm stuck making this damn thing work any way I can (sound familiar to anyone?). – IronicMuffin Dec 04 '09 at 19:36

7 Answers7

10

I think you will face a lot of problems launching an executable server side using the ASPNET identity, have you tried impersonating an identity with appropriate priveleges (this does work btw), but again launching an executable on the server side is probably not a good idea to begin with.

Ta01
  • 31,040
  • 13
  • 70
  • 99
  • 2
    +1 for "launching an executable on the server side is probably not a good idea to begin with" – David Dec 04 '09 at 14:36
  • We actually never got this working, but it is obviously the right road to go down. You're comments above were very helpful in researching a solution. The votes don't lie either, so I'll mark this as the solution. Thanks. – IronicMuffin Dec 09 '09 at 03:45
3

The ASP.Net user account probably doesn't have permissions to execute. Can you give a bit more information as to why you are trying to do this as there may be a better way of doing it.

Burt
  • 7,680
  • 18
  • 71
  • 127
2

It could be a permissions issue. The ASPNET service may have permissions to the executable, but does it have permissions for everything the executable does.

For example, if the executable copies files, does the ASPNET account have full rights to the source and destination paths of those files? The same questions need to be asked of everything the executable does.

If you need to get around this, you can use impersonation, or assign the web site to run under a different account in IIS, but those are not recommended practices, and more trouble than they're worth in most cases.

David
  • 72,686
  • 18
  • 132
  • 173
2

By default the ASP.NET worker process has less security than most local account (certainly an account that a developer uses or the logged in account on a server.)

There are two main ways to move forward:

  1. Give the asp.net process more priviledges. See This Link for a good explanation of how to do that.
  2. Have asp.net run under an account with more priviledges. See This Link for a good explanation and how to get that process running under a different account.

Either will work for you.

Patrick Karcher
  • 22,995
  • 5
  • 52
  • 66
  • I like what is defined in number 2. What kind of security issues does this bring up if it was changed to SYSTEM? This would be sitting on an internal corporate webserver. – IronicMuffin Dec 04 '09 at 14:53
  • Well, that would certainly do the trick. That it is on an internal corporate webserver means that doing so is just bad practice, rather than actually insane. :) Not any worse than leaving the dev db sa account password *sa*. To confirm that impersonating an account with expanded priviledges will do that trick, yeah, just do that. Long term though, I would feel grimey if I didn't create a new account for that. You can even give it super-duper permission, but can scale it back later. And if someone asks how you did this, saying "I made a new account" sounds better than "I gave it system." – Patrick Karcher Dec 05 '09 at 20:22
0

When you redirect standard output don't you need to use ReadToEnd to read the response from StandardOutput?

Lloyd
  • 29,197
  • 4
  • 84
  • 98
0

You probably should check what is your executable performs, cos ASP.NET works under user with limited rights (NETWORK SERVICE on IIS 6.0) and you executable also gets this rights and runs under same user. As far as you waiting on until it finishes its work, probably something wrong in the executable you are trying to run. I suggest you to make a simple experiment - switch your WebApplication to build-in in VS web server, called "Casini" and check your code behavior. By means of this you can prove yourself that it's not ASP.NET's fault. If I am right the only thing you will need to do is to investigate problems of you executable and determine what rights it needs.

Restuta
  • 5,855
  • 33
  • 44
  • Tried it with VS built in web server. Worked great. I'm assuming that's using my credentials all the way through. I think this proves that it *is* ASP .NET's fault, more specifically my impersonation through ASP .NET... – IronicMuffin Dec 04 '09 at 15:52
  • It is fault of that fact that ASP.NET works under limited user rights. This is not ASP.NET's fault, this is issue of your application that requires more rights. – Restuta Dec 21 '09 at 11:01
0

Instead of Impersonation or giving Asp.net more privileges, how about launching the process under different credentials. In the sample below, UserWithVeryLimitedRights would be a new account that you create with just enought rights to run the app. Doing so may minimize the security risks.

ProcessStartInfo StartInfo = new ProcessStartInfo();
SecureString ss = new SecureString();
string insecurePassword = "SomePassword";

foreach(char passChar in insecurePassword.ToCharArray()) {
ss.AppendChar(passChar);
}

StartInfo.RedirectStandardInput = true;
StartInfo.RedirectStandardError = true;
StartInfo.RedirectStandardOutput = true; 

StartInfo.CreateNoWindow = true;
StartInfo.UseShellExecute = false;
StartInfo.Password = ss;
StartInfo.UserName = @"UserWithVeryLimitedRights";
StartInfo.FileName = @"c:\winnt\notepad.exe";
Process.Start(StartInfo);
Mark Maslar
  • 1,121
  • 4
  • 16
  • 28