tracker issue : CF-3795112

select a category, or use search below
(searches all categories and all time range)
Title:

CF9/CF10 - Java Updates 7.51+ break Solr collections

| View in Tracker

Status/Resolution/Reason: Closed/Fixed/

Reporter/Name(from Bugbase): Jack Drysdale Jr / Jack Drysdale Jr (Jack Drysdale Jr)

Created: 07/25/2014

Components: Language, Java Integration

Versions: 10.0

Failure Type: Non Functioning

Found In Build/Fixed In Build: Final / CF10_Update14

Priority/Frequency: Major / Unknown

Locale/System: English / Win All

Vote Count: 0

Problem Description: In both CF9 and CF10, if JDK 7.51 or later is installed, Solr collections will have SocketPermission issues.

Steps to Reproduce:  If JDK 7.51 or later is installed on server and CFAdmin changes Java/JVM setting to point to the update, Solr collections will have SocketPermission issues.

Actual Result:  Error message when trying to search a collection -OR- when trying to access ColdFusion Collections from within CFAdmin:
access denied ("java.net.SocketPermission" "localhost:0" "listen,resolve")

Expected Result:  In application, search results.  In CFAdmin > ColdFusion Collections, a list of collections.

Any Workarounds:  Point Java/JVM back to JVM that installed with ColdFusion Server.  Security issue????

----------------------------- Additional Watson Details -----------------------------

Watson Bug ID:	3795112

External Customer Info:
External Company:  
External Customer Name: WolfShade
External Customer Email:  
External Test Config: My Hardware and Environment details:

DEV:  64-bit Windows7 SP1 - Alienware Area 51 - Intel Core i7 2.8GHz - 12 Gig RAM

PROD: 64-bit Windows Server 2008 - the rest known only to our SA.

Attachments:

Comments:

FYI There were changes made to java default socket permissions in Java 1.7u51, listed here: http://www.oracle.com/technetwork/java/javase/7u51-relnotes-2085002.html The default socket permissions assigned to all code including untrusted code have been changed in this release. Previously, all code was able to bind any socket type to any port number greater than or equal to 1024. It is still possible to bind sockets to the ephemeral port range on each system. The exact range of ephemeral ports varies from one operating system to another, but it is typically in the high range (such as from 49152 to 65535). The new restriction is that binding sockets outside of the ephemeral range now requires an explicit permission in the system security policy. So you should be able to fix this issue by running Solr on a port in the ephemeral range.
Comment by External U.
11519 | August 15, 2014 02:52:58 PM GMT
Another workaround is editing the java security policy file to grant permission to the port solr is using
Comment by External U.
11520 | August 15, 2014 02:55:38 PM GMT
WolfShade, I am unable to reproduce the issue with CF10 update12 on Windows 7 x64 with JDK 1.7.0_55. I don't observe any errors when creating collections, indexing them or using cfsearch on them. Can you share the details on the user account your CF / Jetty service is using. In my case it it the "Local System" account. Where is the error (mentioned in your description) logged?
Comment by Piyush K.
11521 | August 18, 2014 09:57:21 AM GMT
Thank you, Pete and Piyush, for responding. It's been a while since I last did anything with this (I also just got back from vacation), so I'm trying to remember what all I have done, so far. I do know that modifying the config and security files for JVM didn't help, anything - I tried port 0, and also tried a range that included Solr, to no avail. Not sure if I can change the port number that Solr is running on. I mean, I can on my local dev machine, yes, but not production. :( And when I originally submit this, it was affecting only my system, but now it seems to be affecting production, too.. and one of our clients is upset that their PDFs are currently not searchable because of this, so I really need to buckle down and find the solution, for this. V/r, ^_^
Comment by External U.
11522 | August 25, 2014 10:34:09 AM GMT
I did just now notice that Sandbox Security has something to do with it - when turned on, the error is happening; when turned off, it's not an issue. But we cannot turn off Sandbox Security on production.
Comment by External U.
11523 | August 25, 2014 10:35:55 AM GMT
Also, this is CF10 update13 on Windows 7 x64 with JDK 1.7.0_55.
Comment by External U.
11524 | August 25, 2014 10:53:02 AM GMT
A co-worker discovered the solution to the issue we've been having with Java 7.51+ breaking Solr collections on CF9/CF10. I sincerely hope that Adobe plans on including this fix. Modify neo-security.xml as follows: Locate the line that is <var name=' { path to CFIDE } '> (Obviously, enter the path to your CFIDE folder in place of above attribute value.) The next line _should_ define the length of an array. Increase the value by 1. Immediately below that, add the following: <struct> <var name='CLASS'> <string>java.net.SocketPermission</string> </var> <var name='TARGET'> <string>127.0.0.1:0</string> </var> <var name='ACTION'> <string>listen,resolve</string> </var> </struct> Save neo-security.xml, restart CF Application service, and test. HTH, V/r, ^_^
Comment by External U.
11525 | August 29, 2014 07:46:14 AM GMT
UPDATE: Okay.. this did correct the CFAdmin issue of being able to see the collections, but it broke CFSEARCH. So, we had to undo the manual neo-security.xml edit, go into Sandbox Security and click on the entry for CFIDE, then add "127.0.0.1" which enters as "connect,resolve". NOW, manually edit the neo-security.xml file, scroll down to the bottom of /wwwroot/ var, copy and paste the whole struct for 127.0.0.1, give both of them ":0-" to cover the whole range of ports, change the ACTION of the second struct to "listen,resolve", save the file, restart the CF Application service, and test. I'm sure different setups will require different things, but this should serve as a template for what needs to be done.
Comment by External U.
11526 | August 29, 2014 10:20:32 AM GMT
This is the solution that worked for us on CF9: In the default configuration, the neo-security file (<coldfusion>/lib/neo-security.xml) for CF9.1 contain three declarations of socket permissions in the following order: Path: C:\ColdFusion9\wwwroot\WEB-INF\ Permissions: connect, resolve Path: C:\inetpub\wwwroot\CFIDE Permissions: connect, resolve Path: /* Permissions: connect, resolve Manually edit the file and change each of the permissions above to connect, listen, resolve, then restart Coldfusion.
Comment by External U.
11527 | September 03, 2014 12:07:24 PM GMT
this has been fixed for the next update of CF10.
Comment by Piyush K.
11528 | September 04, 2014 02:34:29 AM GMT
Thank you, Piyush! For anyone still running CF9, someone did find a solution very similar to mine: https://forums.adobe.com/thread/1552926
Comment by External U.
11529 | September 05, 2014 08:44:17 AM GMT