E' vero; avevo detto che
avrei parlato di ben altre cose, ma rileggendo la serie di post mi
sono accorto che stavo tralasciando una parte molto
importante. I Named Permissions Sets
. Cosa sono e come funzionano lo scopriremo
nel prossimo post (sec 27). Ho scelto questa scaletta per facilitare la lettura
a chi non avesse familiarità con i Permissions Sets.
Come si può ben intuire
un Set di Permissions è l'unione di due o più Permissions che un assembly può
avere. Ricordiamoci sempre che esistono differenti policies,
ogniuna delle quali con differenti code groups che l'evidence
dell'assembly può soddisfare.
Passiamo alle parti interessanti; Nel caso si
voglia visionare i Permissions Set attivi per il codice in
esecuzione (running assembly) si deve andare ad utilizzare due oggetti
:
Ecco l'esempio
1 using System.Reflection;
2 using System.Security;
3 PermissionSet _ps = SecurityManager.ResolvePolicy(
4 Assembly.GetExecutingAssembly().Evidence);
5 Console.WriteLine("Numero Permissions Sets Usato " + _ps.Count);
6 IEnumerator perms = ps.GetEnumerator();
7 while(_perms.MoveNext())
8 {
9 IPermission p = _perms.Current as IPermission;
10 Console.WriteLine(p.ToString());
11 }
Come si può notare, ResolvePolicy() [riga 3],
prende un oggetto Evidence
e ritorna il set di permissions associato all'evidence
corrente. Dato che l'oggetto Assembly
ha la proprietà Evidence
disponibile, recuperarla non è poi così difficile. Si ha solo
bisogno di prendere l'assembly per il codice attualmente in esecuzione, il quale
può essere recuperato attraverso il GetExecutingAssembly() [riga 4].
Nel caso volessi eseguire questo codice
internamente ad un assembly andrei a ricevere due permissions :
UrlIdentityPermission e ZoneIdentityPermission. Questo perchè ci sono solo tre blocchi di evidence che il mio
assembly presenta a runtime, ovvero: Zone,Url e Hash. Nel caso avessi
avuto uno strong name assembly avrei avuto anche la
StrongNameIdentityPermission.