Bypassare la SecurityException sui provider con livello di trust impostato a Medium

Eccomi qua, di nuovo a narrare la mia ennesima (dis)avventura con i nostri provider nostrani.
Oggi pomeriggio devo mettere online un sito/applicazione per la generazione di preventivi per un mio cliente. I test sono andati alla grandissima, nessun errore, persino nel calcolo degli ammortamenti per i leasing (cosa di cui non mi ero mai occupato...), la grafica piace, i PDF sono perfetti... tutto sul velluto insomma!
Un lavoretto facile, veloce e pulito... sino al momento in cui si è trattato di fare il deploy sull'hosting acquistato dal cliente per l'applicazione (come solito, non farò nomi. Vi dirò soltanto che il provider in questione sta facendo parecchia pubblicità anche in TV in questo periodo...).

Prendo i compilati (gli stessi con i quali sono stati fatti i test)... apro il mio bel client FTP... e cicc e ciac... faccio la copia... patapim e patapem, aspetto la copia... mumble muble, frulla frulla... ok copiato!
Entro nella hompage e sembra "stare insieme". Vedo la pagina principale, nessun errore... dai, partiamo bene!
Navigo un po' per il sito... funziona tutto, anche la seleziona dinamica del background giornaliero!
Provo a fare autenticazione con un utente: funziona alla perfezione! In passato il medesimo provider mi aveva già dato parecchi problemi nell'utilizzo dei componenti standard SqlRoleProvider, SqlMembershipProvider di cui avevamo già ampiamente parlato in questo post ma, come si suol dire, mi freghi una volta sola, non due! ;)

Arrivato a questo punto penso: "Proviamo a fare anche un preventivo di test và... così sono sicuro che funziona tutto, visto che su questo provider non ho mai installato nulla che generasse PDF... ma è più uno scrupolo che altro...".
Piccolo inciso: per generare i PDF, ovviamente, non mi sono voluto appoggiare a costosissime librerie a pagamento, ma di certo non avevo intenzione di "reinventare la ruota", per cui ho utilizzato iTextSharp, porting per il framework .NET dell'omonima libreria in Java, che ho già utilizzato con successo in altre mille mila applicazioni hostate su altri mille mila provider, trovandomici molto bene e senza aver mai avuto il minimo problema.
Entro quindi nella maschera di compilazione dati per il preventivo... inserisco la base di spread... imponibile... frazionamento... numero mensilità... percentuale riscatto... clickette... patapim e patam... CRASH!!!! Con mio stupore mi becco una "bella" (ovviamente, è un eufemismo) schermata di errore di ASP.NET che recita:

Security Exception
Description: The application attempted to perform an operation not allowed by the security policy. To grant this application the required permission please contact your system administrator or change the application's trust level in the configuration file.

Exception Details: System.Security.SecurityException: That assembly does not allow partially trusted callers.

MA WTF????
La mia applicazione è un'applicazione normalissima, non fa nessun "giro strano"... la libreria l'ho stra-iper-utilizzata da altre parti (ed ovviamente, uso sempre i compilati già pronti, per non avere problemi)... PERCHE' MI SI SCHIANTA???

Parte ovviamente la prima sigaretta (ed anche la prima simil-bestemmia della giornata), accendo una candela a san Google e comincio a cercare informazioni sull'errore...
Dopo un'oretta (e molte sigarette dopo) giungo infine al bandolo della matassa: il provider ha (molto "furbescamente") abbassato il livello di Trust di default delle applicazioni da "Full" a "Medium" nel Machine.Config del server, impedendone tra l'altro l'overlod nel Web.Config delle singole applicazioni.
Questo in altre parole si traduce nell'impossibilità di poter effettuare chiamate tra l'assembly della nostra applicazione ed un altro assembly firmato con chiave SNK (come è l'assembly della libreria iTextSharp).. MA PERCHE'???? A CHI GIOVA TUTTO CIO'??
Tra l'altro questa protezione è praticamente inutile, perchè sarebbe sufficiente scrivere del condice unmanaged con direttiva UNSAFE per utilizzare i privilegi di processo e non quelli ereditati dal CAS (Code Access Security), mandando di fatto "a donnine di facili costumi" l'impostazione!

Le soluzioni sono quindi 2: ricompilare l'intera libreria utilizzando la direttiva UNSAFE per tutte le classi (più di 200... escluso!!! e poi, perchè devo indicare come "non sicura" una libreria fantastica con 100% di codice managed??) oppure ricompilare la libreria dando esplicitamente l'allow all'esecuzione di "chiamate parzialmente affidabili" (cioè la mia applicazione).

Scarico quindi i sorgenti della libreria iTextSharp sulla mia macchina, apro il file AssemblyInfo.cs ed aggiungo in coda questa riga:

[assembly: System.Security.AllowPartiallyTrustedCallers]

Ricompilo quindi l'intera libreria e la sostituisco a quella (originale) che è presente sul server... provo nuovamente ad eseguire la generazione del PDF del preventivo... BINGO! FUNZIONA!!!!

Ora mi domando: a quale scopo impostare quella flag di protezione, se è facilmente bypassabile con codice unmanaged (quindi di base "pericoloso") o semplicemente ricompilando un componente aggiungendo una direttiva??
Giusto per "incasinare la vita" ai programmatori, che sono costretti a ricompilarsi la libreria tutte le volte, anzichè utilizzare direttamente i binari???

Mah... solite manie di grandezza dei sistemisti che non sanno dove mettono le mani e fanno solo danni...

Articoli correlati per categorie