Java SecurityManager @Override öffentliche void checkPermission (Permission Permission)

Question

Ich baue eine SWING-Anwendung und muss auch einen benutzerdefinierten SecurityManager schreiben. Wenn ich eine leere Klasse schreiben, die Security wie dies

public class Sandbox extends SecurityManager {} 

Sinn erstreckt es funktioniert gut, dass die GUI korrekt wiedergegeben wird und alle Privilegien wie I/O widerrufen werden. Allerdings muss ich die checkPermission-Methode anpassen und wenn ich es überschreibe nichts mehr funktioniert ... Warum sollte so etwas nicht funktionieren?

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

Update: ein sehr einfaches Beispiel, das das Problem zeigt, ist dies

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); 

} 

die „check“ Methode Entfernen der Anwendung richtig funktioniert, aber ich kann wirklich nicht meinen Kopf bekommen diese um.

Answer 1

Wenn Sie die Superklasse 'checkPermission(p) aufrufen, müssen Sie die Klasse nicht zuerst überschreiben. Kommentieren Sie es, dann funktioniert es.

Die superclas' Anrufe java.security.AccessController.checkPermission(perm) und das scheint eine java.security.AccessControlException zu werfen, wenn sie nicht von java.lang.SecurityManager aufgerufen

in meinem Fall heißt es:

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

usw.

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); 
    } 
} 

gefunden a tutorial zum Schreiben eines Sicherheits-Managers. Ich würde Ihnen auch empfehlen, das Java-Dokument und die Beispiele von Oracle zu lesen.

---

UPDATE

Werfen Sie einen Blick auf die method summary und überschreiben Sie die Funktionalität, die Sie verbieten wollen. Wie ich herausgefunden habe Sie auch müssen explizit die Funktionalität, die Sie haben möchten.

Hier ein Beispiel:

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(); 

    } 
} 

OUTPUT

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

Die Berechtigungen werden basierend auf den gesamten Code auf dem Stack gewährt. Alle Anrufer müssen die erforderliche Erlaubnis haben. Wenn Sie die Methode überschreiben und die Superklassenmethode aufrufen, befindet sich Ihr Code ebenfalls auf dem Stack, was bedeutet, dass Ihre Codebasis (zu der Ihr benutzerdefinierter SecurityManager gehört) die Berechtigung haben muss, nach der Sie (Ihre Anrufer) fragen.

Das ist der Unterschied zwischen dem Überschreiben oder nicht. Wenn Sie diese Methode nicht überschreiben, befindet sich nur der Code des (möglicherweise privilegierten) Aufrufers auf dem Stapel und er erhält die angeforderte Berechtigung. Wenn Sie diese Methode überschreiben, befindet sich Ihr Code ebenfalls auf dem Stack und muss ebenfalls berechtigt sein.

Wenn Sie also einen benutzerdefinierten SecurityManager implementieren möchten, der die geerbte Prüfmethode aufruft, müssen Sie die vererbte (richtlinienbasierte) Logik konfigurieren, um Ihrem SecurityManager alle Berechtigungen zu geben, die er gewähren sollte. Es wird empfohlen, den SecurityManager vom Rest der Anwendung in eine andere Codebasis zu trennen, so dass nur der SecurityManager und sonst nichts die großzügigen Berechtigungen erhält.