13

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 ?

Royi Namir
  • 144,742
  • 138
  • 468
  • 792
  • Hope that chat helped somewhat - to answer your 2 questions: "Who is the account which actually runs cmd.exe ?" => UserA. "To whom "restricted permissions" is actually regarding ?" => restricted permissions refers to the (usual) case of w3wp user being app pool identity, which has reduced rights. In your case, "UserA" – JerKimball Dec 28 '12 at 21:17
  • @JerKimball please notice that Startinfo _does_ provide credentials. – Royi Namir Dec 29 '12 at 20:08
  • Ok, in that case, the new process should launch under the same identity as whatever user/domain you specify in the process start info. – JerKimball Dec 29 '12 at 20:46

3 Answers3

5

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.

JerKimball
  • 16,584
  • 3
  • 43
  • 55
  • Im not using impersonation in my code , it is written in the web.cofig. so the whole site is under impersonation ! – Royi Namir Dec 28 '12 at 19:32
  • 1
    @RoyiNamir, it does not really matter who wrote the code for impersonation - behavior will be exactly the same if using either one that is already part of ASP.Net or some manual one because eventually it will come down to the same native call. Web.config can't change account the worker process runs under - it just triggers impersonation on the threads that run the request. – Alexei Levenkov Dec 28 '12 at 20:16
  • @AlexeiLevenkov so the w3wp user permissions wont have any usages....right ? cause all the threads will be executed by impersonated user. – Royi Namir Dec 28 '12 at 20:18
  • null is not involved here. ( as i run the process with credentials via `startinfo`. forgot to mentione and truly sorry.updated the question.) – Royi Namir Dec 29 '12 at 09:05
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.

OnoSendai
  • 3,960
  • 2
  • 22
  • 46
  • This. By default, the spawned process would be launched as whatever Identity is running the App Pool. The only way to get a process launched as another user context would be to p/invoke it out. – JerKimball Dec 28 '12 at 19:18
  • But as @OnoSendai said, Impersonation happens at the Thread level, Process.Start forks out using P/invoke internally to the win32 call CreateProcessWithLogonW or CreateProcess (depending on if you have UserName set in ProcessStartInfo)...actually, lemme put this in an answer. – JerKimball Dec 28 '12 at 19:24
2

As I found out when trying to solve this problem, lots of little things are different. It may run under RoyiN, but you may find that USERPROFILE is set to C:\Windows\system32\config\systemprofile, and not your /Users/RoyiN folder.

Depending on what you're trying to do, that can cause some problems. In my case, starting a git process would hang forever. Not only were USERPROFILE and HOME wrong, I also found out that impersonated users do not play well with mapped network drives.

Community
  • 1
  • 1
Chris Doggett
  • 19,959
  • 4
  • 61
  • 86