I'm building a SWING application and also need to write a custom SecurityManager. If I write an empty class which extends SecurityManager like this
public class Sandbox extends SecurityManager {}
it works fine, meaning that the GUI is rendered correctly and all privileges like I/O are revoked. However I need to customize the checkPermission method and whenever I override it nothing works anymore... Why even something like this shouldn't work??
public class Sandbox extends SecurityManager {
@Overide
public void checkPermission(Permission perm) {
super.checkPermission(perm);
}
}
Update: a very basic example that shows the problem is this
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);
}
Removing the "checkPermission" method the application works correctly, but I really can't get my head around this.
The security manager is a class that allows applications to implement a security policy. It allows an application to determine, before performing a possibly unsafe or sensitive operation, what the operation is and whether it is being attempted in a security context that allows the operation to be performed.
By default, Java applications have no security restrictions placed on activities requested of the Java API. To use Java security to protect a Java application from performing potentially unsafe actions, you can enable a security manager for the JVM in which the application runs.
When extending the SecurityManager class and overriding existing methods, some care should be taken. For example, if you override the checkRead(String file) method so it always throws a security exception, then the JDK itself may fail to operate properly.
The FileInputStream and SecurityManager classes are system classes for which CodeSource is null and permissions consist of an instance of the AllPermission class, which allows all operations.
The permissions are granted based on all the code on the stack. All callers must have the required permission. If you override the method and call the superclass method, your code is on the stack as well which implies that your codebase (where your custom SecurityManager belongs to) must have the permission you (your callers) ask for.
That’s the difference between overriding or not. If you don’t override that method only the (possibly privileged) caller’s code is on the stack and it will get the requested permission. If you override that method your code is also on the stack and must have the permission as well.
So if you want to implement a custom SecurityManager which invokes the inherited check method you must configure the inherited (policy based) logic to give your SecurityManager all permissions it should be able to grant. It’s recommended to separate the SecurityManager from the rest of the application into a different codebase so only the SecurityManager and nothing else gets the generous permissions.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With