United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6945178 SecurityException upon drag-and-drop
JDK-6945178 : SecurityException upon drag-and-drop

Details
Type:
Bug
Submit Date:
2010-04-19
Status:
Resolved
Updated Date:
2012-09-14
Project Name:
JDK
Resolved Date:
2010-12-21
Component:
client-libs
OS:
windows_vista,solaris_8,linux,windows_xp
Sub-Component:
java.awt
CPU:
x86
Priority:
P2
Resolution:
Fixed
Affected Versions:
6u10,6u19,6u20
Fixed Versions:

Related Reports
Backport:
Backport:
Backport:
Duplicate:
Duplicate:
Duplicate:
Duplicate:
Duplicate:
Duplicate:

Sub Tasks

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

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.
                                     
2010-04-26
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.
                                     
2010-05-05
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.
                                     
2010-05-07
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.
                                     
2010-05-07
SUGGESTED FIX

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

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



Hardware and Software, Engineered to Work Together