Java SecurityManager @Override public void checkPermission (Permission perm)

Question

Sto costruendo un'applicazione SWING e anche bisogno di scrivere un personalizzato SecurityManager. Se scrivo una classe vuota che si estende SecurityManager come questo

public class Sandbox extends SecurityManager {} 

funziona bene, il che significa che l'interfaccia grafica è resa in modo corretto e tutti i privilegi come I/O sono revocato. Tuttavia ho bisogno di personalizzare il metodo checkPermission e ogni volta che l'override che niente funziona più ... Perché anche qualcosa come questo non dovrebbe funzionare ??

public class Sandbox extends SecurityManager { 
    @Overide 
    public void checkPermission(Permission perm) { 
    super.checkPermission(perm); 
    } 
} 

Update: un esempio molto semplice che mostra il problema è questo

public static void main(String[] args) { 

    System.setSecurityManager(new SecurityManager() { 
     @Override 
     public void checkPermission(Permission p) { 
      if (some_condition_here) { 
       // Do something here 
      } else { 
       // Resort to default implementation 
       super.checkPermission(p); 
      } 
     } 
    }); 

    new JFrame().setVisible(true); 

} 

Rimozione del metodo di "checkPermission" l'applicazione funziona correttamente, ma davvero non può ottenere la mia testa intorno a questo.

Answer 1

Se si chiama la superclasse checkPermission(p) non c'era bisogno di sostituire la classe, in primo luogo. Commentalo, poi funziona.

I superclas' chiamate java.security.AccessController.checkPermission(perm) e che sembra gettare un java.security.AccessControlException, quando non è invocata da java.lang.SecurityManager

nel mio caso si dice:

Could not load Logmanager "null" 
java.security.AccessControlException: access denied (java.util.PropertyPermission java.util.logging.manager read) 

ecc

public class SecurityManagerExample 
{ 
    public static void main(String[] args) 
    { 
    System.setSecurityManager(new SecurityManager() 
    { 
     @Override 
     public void checkPermission(Permission p) 
     { 
     //super.checkPermission(p); 
     } 
    }); 

    new JFrame().setVisible(true); 
    } 
} 

ho trovato a tutorial su come scrivere un gestore della sicurezza. Ti consiglio anche di consultare il documento java e gli esempi forniti da oracle.

---

UPDATE

Date un'occhiata al method summary e sovrascrivere la funzionalità che si desidera proibire. Come ho scoperto che anche necessità di consentire in modo esplicito le funzionalità che si desidera avere.

Ecco un esempio:

public class SecurityManagerExample 
{ 

    public static void main(String[] args) 
    { 
    System.setSecurityManager(new SecurityManager() 
    { 
     @Override 
     public void checkWrite(String file) { 
     // no exception is thrown, i. e. creating files is allowed in general 
     } 

     @Override 
     public void checkDelete(String file) 
     { 
     if (file.equals("test.xml")) 
     { 
      throw new SecurityException("Not allowed to delete test.xml!"); 
     } 
     } 
    }); 

    File f = new File("test.xml"); 
    try 
    { 
     f.createNewFile(); 
    } 
    catch (IOException e) 
    { 
    } 

    f.delete(); 

    } 
} 

USCITA

Exception in thread "main" java.lang.SecurityException: Not allowed to delete test.xml! 
    at main.SecurityManagerExample$1.checkDelete(SecurityManagerExample.java:60) 
    at java.io.File.delete(File.java:902) 
    at main.SecurityManagerExample.main(SecurityManagerExample.java:74) 

Answer 2

I permessi sono concessi sulla base di tutto il codice in pila. Tutti i chiamanti devono avere il permesso richiesto. Se si esegue l'override del metodo e chiama il metodo della superclasse, il codice è in pila così che implica che la vostra base di codice (dove la vostra abitudine SecurityManager appartiene) deve avere il permesso voi (i chiamanti) chiedere.

Questa è la differenza tra l'override o meno. Se non ignorare che il metodo solo il codice del (forse privilegiato) del chiamante è in pila e si otterrà il permesso richiesto. Se si sostituisce quel metodo, anche il codice è in pila e deve avere anche il permesso.

Quindi, se si desidera implementare un SecurityManager personalizzato che richiama il metodo di controllo ereditato, è necessario configurare la logica ereditata (basata su criteri) per fornire a SecurityManager tutte le autorizzazioni che dovrebbe essere in grado di garantire. Si consiglia di separare SecurityManager dal resto dell'applicazione in una base di codice diversa in modo che solo SecurityManager e nient'altro ottengano le autorizzazioni generose.