SemaforoE' 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 :

  • SecurityManager
  • Assembly

Ecco l'esempio

 using System.Reflection;
 
using System.Security;
 PermissionSet _ps = SecurityManager.ResolvePolicy(
    Assembly.GetExecutingAssembly().Evidence);
 Console.WriteLine("Numero Permissions Sets Usato " + _ps.Count);
 IEnumerator perms = ps.GetEnumerator();
 
while(_perms.MoveNext())
 {
    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.