CF2018 Sandbox Security database connections only work when using IP addresses in datasources

[vertizonal]

Just restricting CFExecute and CFRegistry for now in the website and custom tags directory. All datasources are allowed, and nothing else is restricted.

When using names for datasources (which works Sandbox Security unchecked), I get the following upon restart:

Error [ajp-nio-127.0.0.1-8018-exec-1] - Error Executing Database Query.''

This is on localhosts with Windows 11. One Windows 10 localhost appears to work fine with server names in the datasources, although there might be something else going on with that setup that isn't obvious.

The most I could track down with this is that it appears that Java Security Manager takes over database connections once Sandbox Security is enabled. Maybe Java Security Manager just allows IPs? I couldn't find anything related to that.

I don't want to apply this on our live server without understanding why only IPs work, if this is the case, or if something more serious is set up incorrectly with our servers.

Any help on this would be greatly appreciated.

[BKBK]

Please have a look at the log files, and share all the relevant information you find. There should be an error message telling you what happened. 

[Dave Watts]

Just for fun, try removing CFEXECUTE from your sandbox security limitations. I'm guessing that might fix the problem. Let us know if that's what happens!

Dave Watts, Eidolon LLC

[vertizonal]

Thanks for the reply, Dave. Unfortunately, removing CFEXECUTE as a blocked tag from all the Sandboxes didn't help.

[Dave Watts]

It was kind of a long shot. Basically, when you use a DNS name instead of an IP address anywhere, something has to look that up. For your browser, it's your OS, which talks to the nameserver it's supposed to use, which in turn talks to the authoritative nameserver, and answers come back to your OS and eventually your browser. For JDBC datasources, JDBC uses JNDI (I think) to get the answers back. I thought the rule blocking CFEXECUTE might also be accidentally blocking JDBC & JNDI. Apparently not!

You should probably look at the log files, like @BKBK already suggested. Good luck!

Dave Watts, Eidolon LLC

[vertizonal]

I got it working with the DNS name by editing the hosts file on my localhost. Not sure if this is the "right" solution or not, though. The server that it is connecting to for the datasource is an internal server. Maybe it can't do lookups correctly for internal servers?

Not sure what other log files to look at. The error line above came from coldfusion-out.log. Coldfusion-error.log has "null" a number of times on their own lines. The only other thing I can think of that might be of use is this:

Loading class `com.mysql.jdbc.Driver'. This is deprecated. The new driver class is `com.mysql.cj.jdbc.Driver'. The driver is automatically registered via the SPI and manual loading of the driver class is generally unnecessary.

[Dave Watts]

Editing your hosts file is a clever but kind of clunky solution. Make sure you write that down somewhere! That does avoid the network lookup that would be needed to resolve the name from the registered nameserver. But it also puts the onus on you to remember you did this, in case that name ever points to a different IP or CNAME etc in the future.

There is a potential hint in the error message you displayed. The new driver class uses something called Connector/J.

https://dev.mysql.com/doc/connector-j/8.0/en/connector-j-usagenotes-connect-drivermanager.html

It might be the case that this new driver is talking to the network in a way that doesn't work with security sandboxes, and the old driver didn't. So I think you probably have enough information to open a ticket with Adobe.

Dave Watts, Eidolon LLC