JDK-6945178 : SecurityException upon drag-and-drop
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 6u10,6u19,6u20
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS:
    linux,solaris_8,windows_xp,windows_vista linux,solaris_8,windows_xp,windows_vista
  • CPU: x86
  • Submitted: 2010-04-19
  • Updated: 2012-09-14
  • Resolved: 2010-12-21
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other JDK 6 JDK 7
1.4.2_27Fixed 6u21Fixed 7 b123Fixed
Related Reports
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Description
FULL PRODUCT VERSION :
java version "1.6.0_20"
Java(TM) SE Runtime Environment (build 1.6.0_20-b02)
Java HotSpot(TM) Client VM (build 16.3-b01, mixed mode, sharing)


ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows XP [Version 5.1.2600]

A DESCRIPTION OF THE PROBLEM :
Drag-and-drop code that was working fine prior to Java 6 Update 19 started failing with a SecurityException in Java 6 Update 19 and continues to fail in Java 6 Update 20 in Transferable.getTransferData(DataFlavor) in cases where the Transferable was obtained as part of a drag-and-drop operation.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
This bug is reproducible with any drop-target handling code in any applet -- unless the getTransferData() call is wrapped in a PrivilegedAction.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
I would expect no such SecurityException as all the Javadoc for getTransferData(), both on Transferable and on DropTargetContext.TransferableProxy fails to mention any possibility of a SecurityException occuring.  Moreover all Java Plug-In versions prior to Java 6 Update 19 did not produce a SecurityException in the same circumstances, going all the way back to Java 1.3.
ACTUAL -
The actual result is a SecurityException blocking the drag-and-drop operation from succeeding.

ERROR MESSAGES/STACK TRACES THAT OCCUR :
Exception in thread "AWT-EventQueue-2" java.security.AccessControlException: access denied (java.awt.AWTPermission accessClipboard)
         at java.security.AccessControlContext.checkPermission(Unknown Source)
         at java.security.AccessController.checkPermission(Unknown Source)
         at java.lang.SecurityManager.checkPermission(Unknown Source)
         at java.lang.SecurityManager.checkSystemClipboardAccess(Unknown Source)
         at sun.awt.dnd.SunDropTargetContextPeer.getTransferData(Unknown Source)
         at sun.awt.datatransfer.TransferableProxy.getTransferData(Unknown Source)
         at java.awt.dnd.DropTargetContext$TransferableProxy.getTransferData(Unknown Source)
         ....

REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
The only workaround appears to be to wrap the getTransferData() call in a PrivilegedAction and sign the jar in question.  I have done this and it works fine.  There are issues here, however.  Transferable.getTransferData() is a fairly high level API in some respects.  One can't really make just the attempt to get transfer data from the native drop peer privileged.  Instead one ends up making a lot more than that privileged by wrapping this API in a privileged API block, which is rather unfortunate.

Overall it would appear that this change is an intentional security fix.  If so, documentation is needed to show what all changed (was it just this API?) so that developers can work around the issue.  Also, if this was intentional, then some clear heads-up that perfectly valid applications are likely to break with this update was clearly needed here -- our customers found this before we did thanks to the lack of adequate notice.

Release Regression From : 6u18
The above release value was the last known release where this 
bug was not reproducible. Since then there has been a regression.

Comments
EVALUATION http://hg.openjdk.java.net/jdk7/build/jdk/rev/386b49abc195
25-12-2010

SUGGESTED FIX http://sa.sfbay.sun.com/projects/awt_data/7/6945178.0/
01-12-2010

EVALUATION This issue consists of two parts. 1.java.awt.AWTPermission accessClipboard is printed in the moment of drag over a potential drag target that has installed SecurityManager but does not have the permission. This behavior is normal. 2.java.awt.AWTPermission accessClipboard is printed on drop this is not expected behavior and it should be fixed. See suggested fix for more details.
07-05-2010

SUGGESTED FIX Currently algorithm that analyses whether getting transferred data should be permitted takes into account a dropComplete flag. This flag should be set after user had accepted drop action. For the reason that getting transferred data can be a key point to accept a drop we should not take into consideration dropComplete flag. Instead, we could check the clipboard permission presence before user listener invocation.
07-05-2010

EVALUATION This is expected behavior and it is caused by 6u19 security fix 6887703, we need to add notes in release note to describe it. No fixed will be provided.
05-05-2010

EVALUATION See comments section please. To deal with the current implementation an applet have to be signed, or has the AWTPermission.accessClipboard permission. Otherwise the applet should not try to get data from drag source during drag over action.
26-04-2010