SharePoint 2007 - RunWithElevatedPrivileges - Le insidie ​​dell'utilizzo di questo

Question

Ho un forte istinto nel ritenere che l'utilizzo di SharePoint RunWithElevatedPrivileges dovrebbe essere evitato come la peste, ma è necessario convincere alcuni altri del perché esattamente. Ecco cosa ho.

• genera un nuovo thread con privilegi elevati
• Blocchi altre operazioni fino a quando il delegato passato ritorna
• problemi di sicurezza (corre con un alto livello di privilegi, forse da un utente finale)
• altri?

Answer 1

motivi per elevare rientrano in due categorie:

1. Il codice ha bisogno di eseguire operazioni in SharePoint per i quali l'utente corrente non dispone delle autorizzazioni. Ciò dovrebbe sempre essere eseguito mentre si lavora con la sicurezza di SharePoint, non come una misura "just in case" che indica che è necessario comprendere meglio la propria situazione di sicurezza.
2. Il codice deve accedere a risorse esterne (file system del server, database, condivisione file, ecc.) A cui l'identità del pool di applicazioni ha accesso ma l'utente corrente no.

Per il primo, è molto meglio usare SPSite impersonation. Quest'ultima è l'unica ragione per cui utilizzo RWEP.

Per chiarire, RWEP non genera un nuovo thread. Invece utilizza le API Win32 per ripristinare l'identità del thread corrente all'identità del processo (disattivando la rappresentazione) per eseguire il codice elevato, quindi riattivare la rappresentazione per riprendere il lavoro per conto dell'utente corrente. Questo ha diverse implicazioni:

1. RWEP non fa nulla se il filo non viene rappresentato, quindi è inutile in processi timer, flussi di lavoro di Visual Studio, applicazioni console ed eseguire codice tramite stsadm (funzione ricevitori).
2. L'accesso a SharePoint, presupponendo che venga creato un nuovo SPSite nel proprio CodeToRunElevated, verrà eseguito con i diritti del pool di applicazioni (SHAREPOINT \ system). Questo account avrà pieno accesso all'applicazione web corrente, ma non dovrebbe avere autorizzazioni a livello di farm per fare cose come modificare proprietà SPFarm o apportare modifiche al provider di servizi condivisi.
3. L'utilizzo di oggetti sensibili all'identità (come SPSite e i suoi figli) attraverso i limiti di esecuzione del tuo CodeToRunElevated ha il potenziale di causare alcuni comportamenti davvero funky e condizioni di gara. Per tutti gli effetti, considera questo non supportato.

E come ha detto Alex, i figli di un SPSite ereditano le loro autorizzazioni dal SPSite, che a sua volta ha le sue autorizzazioni impostate al momento della creazione. Quindi SPContext.Current.Site continuerà a comportarsi con le autorizzazioni dell'utente corrente anche se lo si fa riferimento all'interno di CodeToRunElevated. Invece, dovresti creare e consumare un nuovo SPSite all'interno del blocco sopraelevato.

Per riepilogare: RWEP per impersonare il pool di app al di fuori di SharePoint, rappresentazione SPSite per impersonare il pool di app all'interno di SharePoint.

Answer 2

RWEP, come tutto il resto, hanno pro e contro.

Se sei preoccupato per l'utente finale che esegue RWEP, probabilmente hai già un problema più grande, poiché quel codice è già stato installato su GAC.

A volte, è sufficiente attenersi ad esso: considerare un utente che non dispone di diritti di amministrazione, eseguendo un flusso di lavoro del documento. Dopo che questo utente ha approvato (o rifiutato, non ha importanza), il motore del flusso di lavoro dovrebbe essere in grado di ridefinire i privilegi di SPListItem.

Answer 3

Lo uso e lo trovo molto utile. A mio avviso, sto scegliendo di consentire all'utente di eseguire il mio codice e fare in modo che quel codice faccia cose che l'utente normalmente non potrebbe fare. È possibile bloccare qualcosa e consentire comunque all'utente di accedervi in ​​modo molto controllato.

Answer 4

1) L'uso sostanziale di RWEP è una buona indicazione degli odori di codice. Può essere facilmente abusato senza pensieri, il che porta a seri problemi di sicurezza. Molti sviluppatori non pensano a cosa gli utenti potrebbero fare con il potere a loro indirettamente dato "sotto il cofano".

Solo un esempio: è importante chiamare ValidateFormDigest prima di utilizzare RWEP su prevent malicious requests in application pages.

---

2) SPWeb e SPSite oggetti devono essere creati nel contesto di RWEP. Questo è facile da dimenticare per gli sviluppatori principianti, portando a molte frustrazioni.

Questa restrizione significa anche che tutto il lavoro e tutti gli oggetti creati da questi oggetti devono essere utilizzati e completati prima della fine del delegato RWEP. Questo è un altro errore comune.

Keith Dahlby ha scritto extension methods per aggirare questi problemi, fornendo un codice più robusto e leggibile.