2012-12-28 10 views
12

Secondo msdn:Process.Start() sotto asp.net?

ASP.NET pagina Web e codice di controllo Server esegue nel contesto del processo di lavoro ASP.NET sul server Web. Se si utilizza il metodo Start in una pagina Web ASP.NET o controllo server, il nuovo processo viene eseguito sul server Web con autorizzazioni limitate. Il processo non si avvia nello stesso contesto del browser client e non ha accesso al desktop dell'utente.

Qualiconto è proprio il "autorizzazioni limitate" ?

Esempio:

  • sono connesso a win7 come RoyiN
  • autenticazione di Windows è abilitato
  • sostituzione di persona è abilitato come BobKa web.config (in tutto il sito
  • L'utente W3WP è UserA (non di rete né ApplicationPoolIdentity).

In C# che faccio Process.start("....cmd.exe...") (conStartinfo credenziali come: "Martin", "Password", "Domain")

  • Chi è l'efficiente account che alla fine corre cmd.exe?

  • A chi "autorizzazioni ristrette" sta effettivamente parlando?

+0

Spero che la chat abbia aiutato un po '- per rispondere alle tue 2 domande: "Chi è l'account che esegue effettivamente cmd.exe?" => UtenteA. "A chi" permessi limitati "sta effettivamente parlando?" => autorizzazioni riservate si riferisce al (solito) caso in cui l'utente w3wp è l'identità del pool di app, che ha diritti ridotti. Nel tuo caso, "UtenteA" – JerKimball

+0

@JerKimball, notare che Startinfo _de_ fornisce credenziali. –

+0

Ok, in tal caso, il nuovo processo dovrebbe essere avviato con la stessa identità di qualsiasi utente/dominio specificato nelle informazioni di avvio del processo. – JerKimball

risposta

5

rappresentazione non entrerà in gioco qui, dal momento che sotto il cofano, Process.Start fa affidamento su uno dei due Win32 nativa chiamate:

Se ProcessStartInfo.UserName è previsto:

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

CreateProcessWithLogonW

E se no:

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

CreateProcess

Gli null s passati in CreateProcess sono quelli che probabilmente ti stanno mordendo; da MSDN:

Il membro lpSecurityDescriptor della struttura specifica un descrittore di sicurezza per il thread principale. Se lpThreadAttributes è NULL o lpSecurityDescriptor è NULL, il thread ottiene un descrittore di sicurezza predefinito . Gli ACL nel descrittore di sicurezza predefinito per un thread provengono dal token di processo.

Nota dice dal token di processo, non chiama il thread: l'identità rappresentata non ha la possibilità di unirsi alla festa poiché è legata alla discussione.

+0

Non sto usando la rappresentazione nel mio codice, è scritto nel web.cofig. quindi l'intero sito è sotto controllo! –

+1

@RoyiNamir, non importa chi ha scritto il codice per la rappresentazione - il comportamento sarà esattamente lo stesso se si utilizza uno che fa già parte di ASP.Net o di uno manuale perché alla fine arriverà alla stessa chiamata nativa. Web.config non è in grado di modificare l'account in cui viene eseguito il processo di lavoro, ma fa scattare la rappresentazione sui thread che eseguono la richiesta. –

+0

@AlexeiLevenkov quindi le autorizzazioni utente w3wp non avranno alcun utilizzo .... giusto? perché tutti i thread saranno eseguiti da un utente impersonato. –

2

credo che la voce di MSDN si riferisce al fatto che, anche se la rappresentazione è attivata e si è in un contesto di utente specifico, il nuovo processo verrà generato dal processo - e la rappresentazione avviene a livello di thread. Detto questo, credo che funzionerebbe sotto il contesto "UserA".

Ecco l'entrata KB pertinente:

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

Si noti che la stessa voce descrive come utilizzare CreateProcessAsUser per consentire la rappresentazione.

+0

Questo. Per impostazione predefinita, il processo generato verrebbe avviato come qualsiasi identità esegua il pool di applicazioni. L'unico modo per avviare un processo come un altro contesto utente è p/invocarlo. – JerKimball

+0

@JerKimball ma la rappresentazione ha la precedenza su utente w3wp ..... –

+0

Tuttavia, come @OnoSendai ha affermato, l'impersonificazione avviene a livello di thread, Process.Start si estrae utilizzando P/invoca internamente alla chiamata win32 CreateProcessWithLogonW o CreateProcess (a seconda se si dispone UserName impostato in ProcessStartInfo) ... in realtà, lemme metti questo in una risposta. – JerKimball

2

Come ho scoperto quando ho provato a risolvere this problem, molte piccole cose sono diverse. Può essere eseguito con RoyiN, ma è possibile che USERPROFILE sia impostato su C: \ Windows \ system32 \ config \ systemprofile e non sulla cartella/Users/RoyiN.

A seconda di cosa si sta tentando di fare, ciò può causare alcuni problemi. Nel mio caso, l'avvio di un processo Git sarebbe rimasto per sempre.Non solo sono stati errati USERPROFILE e HOME, ma ho anche scoperto che gli utenti impersonati non giocano bene con le unità di rete mappate.

Problemi correlati