One of things that I'm thinking of proposing is to deprecate the     checkTopLevelWindow, checkSystemClipboardAccess and     checkTopLevelWindow methods that are defined by     java.lang.SecurityManager. The motivation is modularity as these 3     methods have a specified dependency on java.awt.AWTPermission. For     now we use reflection to avoid the static dependency but I would     like to eliminate the dependency completely if we can. The other     point is that these methods are completely obsolete and haven't     really need needed since SecurityManager.checkPermission was added     in JDK 1.2.
    
    If deprecated then the proposal would be to change the 3 methods in     some future release so that they are specified to check     AllPermission rather than AWTPermission("xyz"). This would be     consistent to how we have already changed these methods to work with     compact Profiles of Java SE that do not have AWT.
    
    I would like to explore the implications of this and specifically on     the following AWT methods/constructors that are specified to involve     these security manager methods:
    
    java.awt.Toolkit.getSystemClipboard
    java.awt.Toolkit.getSystemSelection
    java.awt.Toolkit.          getSystemEventQueue
    java.awt.Window(Frame)
    java.awt.Window(Window)
    java.awt.Winow.getWarningString()
    
    Can anyone see any issues with changing the spec and implementation     of these methods to use SecurityManager's checkPermission directly?     The ultimate permission check would be the same as now so it     shouldn't require anyone to adjust security policies. 
    
    Clearly custom security managers that override checkTopLevelWindow,     checkSystemClipboardAccess and checkTopLevelWindow will see a     difference in that checkPermission will be called directly. Also     anyone depending on stack depth or anything fragile like that will     break.
    
    Thanks,
    
    -Alan.
    
    
    
    
   ">

(original) (raw)


One of things that I'm thinking of proposing is to deprecate the checkTopLevelWindow, checkSystemClipboardAccess and checkTopLevelWindow methods that are defined by java.lang.SecurityManager. The motivation is modularity as these 3 methods have a specified dependency on java.awt.AWTPermission. For now we use reflection to avoid the static dependency but I would like to eliminate the dependency completely if we can. The other point is that these methods are completely obsolete and haven't really need needed since SecurityManager.checkPermission was added in JDK 1.2.

If deprecated then the proposal would be to change the 3 methods in some future release so that they are specified to check AllPermission rather than AWTPermission("xyz"). This would be consistent to how we have already changed these methods to work with compact Profiles of Java SE that do not have AWT.

I would like to explore the implications of this and specifically on the following AWT methods/constructors that are specified to involve these security manager methods:

java.awt.Toolkit.getSystemClipboard
java.awt.Toolkit.getSystemSelection
java.awt.Toolkit. getSystemEventQueue
java.awt.Window(Frame)
java.awt.Window(Window)
java.awt.Winow.getWarningString()

Can anyone see any issues with changing the spec and implementation of these methods to use SecurityManager's checkPermission directly? The ultimate permission check would be the same as now so it shouldn't require anyone to adjust security policies.

Clearly custom security managers that override checkTopLevelWindow, checkSystemClipboardAccess and checkTopLevelWindow will see a difference in that checkPermission will be called directly. Also anyone depending on stack depth or anything fragile like that will break.

Thanks,

\-Alan.