Essere a casa influenzato non porta solo svantaggi. Solo ora, ho trovato, un errore all'interno di una mia vecchia, ma ancora funzionante applicazione.
Ecco la classe
Il codice sembra corretto, e guardandolo così com'è non si nota alcun tipo di errore. In realtà l'errore c'è ma non si vede. Come la maggior parte delle applicazioni che vengono sviluppate a seguito del build non si esegue mai alcun tipo d'intervento sulle permissions a livello di assembly.
In questo caso è possibile eseguire il codice pur non avendone l'autorizzazione. (ND nel mio caso giravo l'assembly con un utente remoto)
In .NET è possibile, come in altri linguaggi di programmazione, creare una identità totalmente falsa ma corrispondente ai requisiti di sicurezza del metodo che si ha intenzione di chiamare. Creato il metodo, ed impersonata la falsa identità si può facilmente eseguire il codice.
Ecco il codice che "crakka" la PrincipalPermission del metodo AdminsOperations().
Lo snippet di codice non fa altro che creare una utenza al 100% simile a quella richiesta, la quale viene passata ad una Intefaccia IPrincipal creata attraverso una GenericPrincipal. Fatto questo, assegna al Thread Corrent l'utenza appena realizzata.
Come evitare questo?
Ammetto di averci perso la testa per una ventina di minuti buoni, fino a quando non ho iniziato a ragionare nel migliore dei modi (partire dalle cose + semplici). E' necessario negare il controllo Principal dall'assembly in questione. Una volta eliminato il flag dal menu Permission Settings, il codice "hack" non funziona più.