Process.Start() under asp.net?

Question

According to msdn :

ASP.NET Web page and server control code executes in the context of the ASP.NET worker process on the Web server. If you use the Start method in an ASP.NET Web page or server control, the new process executes on the Web server with restricted permissions. The process does not start in the same context as the client browser, and does not have access to the user desktop.

Which account precisely is the "restricted permissions" ?

Example :

• I'm logged to win7 as RoyiN
• windows authentication is enabled
• Impersonation is enabled as BobK at web.config ( all over the site)
• The W3WP user is UserA (not network nor ApplicationPoolIdentity).

In C# I do Process.start("....cmd.exe...") ( with Startinfo credentials as : "Martin","Password","Domain")

• Who is the efficient account which finally runs cmd.exe ?

• To whom "restricted permissions" is actually regarding ?

Answer 1

Impersonation won't come into play here, since under the hood, Process.Start is relying on one of two native Win32 calls:

If ProcessStartInfo.UserName is provided:

CreateProcessWithLogonW(startInfo.UserName, startInfo.Domain, ...)

CreateProcessWithLogonW

And if not:

CreateProcess(null, cmdLine, null, null, true, ...)

CreateProcess

The nulls passed into CreateProcess are what's probably biting you; from MSDN:

The lpSecurityDescriptor member of the structure specifies a security descriptor for the main thread. If lpThreadAttributes is NULL or lpSecurityDescriptor is NULL, the thread gets a default security descriptor. The ACLs in the default security descriptor for a thread come from the process token.

Note it says from process token, not calling thread - the impersonated identity doesn't get a chance to join the party since it's bound to the thread.

Answer 2

I believe the MSDN entry refers to the fact that even if impersonation is enabled and you're under a specific user context, the new process will be spawned by the process - and impersonation occurs at thread level. That said, i do believe it would run under the 'UserA' context.

Here's the pertinent KB entry:

http://support.microsoft.com/kb/889251

Notice that the same entry describes how to use CreateProcessAsUser to allow for impersonation.