从ASP.NET应用程序池标识运行命令

I am running an executable process from my ASP.NET application when a user clicks a button. This process creates several files and serves them up to the end-user. I can't really see what the process is or isn't doing, but it didn't work until I specified the admin user as the application pool identity on the server. I am using IIS7.

当用户单击按钮时,我正在从ASP.NET应用程序运行可执行进程。此过程会创建多个文件,并将其提供给最终用户。我无法确切地看到进程是做什么或者没做什么,但是直到我将admin用户指定为服务器上的应用程序池标识才行。我正在使用IIS7。

 using (var proc = new Process())
 {
    proc.StartInfo.FileName = Server.MapPath("~/Testing/Demo/MyExe.exe");
    proc.StartInfo.Arguments = String.Format("\"{0}\"", commandFilePath);
    proc.StartInfo.UseShellExecute = true;
    proc.Start();
    proc.WaitForExit();
 }

I'm assuming that this is generally a bad thing to do. Can you give me insight into what needs to be done in order to enable this for the normal ApplicationPoolIdentity account?

我认为这通常是一件坏事。您能否让我深入了解为正常的ApplicationPoolIdentity帐户启用此操作需要做些什么?

Thanks!

4 个解决方案

#1

First of all, why you need the Shell to execute it ? Isn't a console application - do you open any window ?

首先,为什么需要Shell来执行它?不是控制台应用程序 - 你打开任何窗口吗?

Second you need to redirect the input and the output.

其次,您需要重定向输入和输出。

And final, what you need to do, is to place on the directory that your script runs, permission for the user under witch your pool is run. And remove the Admin from your pool.

最后,您需要做的是放置脚本运行的目录,运行池下的用户权限。并从池中删除管理员。

proc.StartInfo.UseShellExecute = false;
proc.StartInfo.CreateNoWindow = false;
proc.StartInfo.RedirectStandardError = true;
proc.StartInfo.RedirectStandardOutput = true;
proc.StartInfo.RedirectStandardInput = true;

proc.Start();

proc.StandardInput.Flush();
proc.StandardInput.Close();

proc.WaitForExit();
proc.Close();

So for example, if you add your pool to run under the UserA, then go to your directory that your program runs and add permission for the UserA to been able to execute programs on that directory. If your program also use other directories to read and write, also add permission to the UserA for that ones.

因此,例如,如果将池添加到UserA下运行,则转到程序运行的目录,并为UserA添加权限,以便能够在该目录上执行程序。如果您的程序还使用其他目录进行读写,则还要为UserA添加权限。

I can't really see what the process is or isn't doing

我无法真正看到过程是做什么或不做什么

You can take a look if you use on the server the Process Explorer and see if its runs, if its close, if its stop but stay there.

您可以查看一下,如果您在服务器上使用Process Explorer并查看它是否运行,如果它关闭,如果它停止但保持在那里。

#2

It is likely a file/execution permissions issue. Try granting execute permissions to the ApplicationPoolIdentity to ~/Testing/Dema/MyExe.exe and read permissions to commandFilePath. You mentioned that your process creates files. You will need to grant either modify or full control permissions to the ApplicationPoolIdentity on the folder where the files will be created. Here is a matrixed list of permissions.

它可能是文件/执行权限问题。尝试将ApplicationPoolIdentity的执行权限授予〜/ Testing / Dema / MyExe.exe并读取commandFilePath的权限。您提到过程会创建文件。您需要为将要创建文件的文件夹的ApplicationPoolIdentity授予修改或完全控制权限。这是一个矩阵的权限列表。

See assign permissions to ApplicationPoolIdentity account for information on granting permissions.

有关授予权限的信息,请参阅为ApplicationPoolIdentity帐户分配权限。

The security event log should capture permission denied errors. Check there to see if you have access permission issues. The System and application logs might also contain information on the problem.

安全事件日志应捕获权限被拒绝的错误。检查那里是否有访问权限问题。系统和应用程序日志还可能包含有关该问题的信息。

Process Explorer can also show File Access requests. Here is a technet article on troubleshooting with Process Explorer.

Process Explorer还可以显示文件访问请求。这是一篇关于使用Process Explorer进行故障排除的technet文章。

#3

Whenever you run any process from an ASP.NET page, it runs under the security context of the worker process, the privilege of your app pool account. It is not like you normally running the MyExe.exe, in that case it will run using logged in account. It is because of this, your code worked when you gave Admin account to app pool.

无论何时从ASP.NET页面运行任何进程,它都在工作进程的安全上下文中运行,即应用程序池帐户的权限。它与您正常运行MyExe.exe不同,在这种情况下,它将使用登录帐户运行。正因为如此,当您将管理员帐户提供给应用程序池时,您的代码才有效。

There are many ways to solve this issue.

有很多方法可以解决这个问题。

One of the easiest would be to change your app pool identity to Network Service and add the Network Service to permissions of the folders in which the MyExe.exe will be accessing files form.

最简单的方法之一是将您的应用程序池标识更改为网络服务,并将网络服务添加到MyExe.exe将访问文件表单的文件夹的权限。

Hope it helps.

希望能帮助到你。

#4

Thank you all for your help. All I needed to do was set the StartInfo.WorkingDirectory to somewhere that I was able to write.

感谢大家的帮助。我需要做的就是将StartInfo.WorkingDirectory设置为我能写的地方。

        using (var proc = new Process())
        {
            proc.StartInfo.FileName = Server.MapPath("~/Testing/Demo/MyEXE.exe");
            proc.StartInfo.Arguments = String.Format("\"{0}\"", commandFile);
            proc.StartInfo.WorkingDirectory = savePath;
            proc.Start();
            proc.WaitForExit();
        }

This causes the temp files to be written to a non-system folder and thus does not need any elevated permissions for the application pool.

这会导致临时文件写入非系统文件夹,因此不需要任何提升的应用程序池权限。

#1