Bug 738814
Summary: | Access denied at ssl handshake | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Omair Majid <omajid> |
Component: | icedtea-web | Assignee: | Omair Majid <omajid> |
Status: | CLOSED WORKSFORME | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 15 | CC: | dbhole, don-redhat-z6y, omajid |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2011-09-23 15:44:02 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Omair Majid
2011-09-15 21:09:55 UTC
The url for this is http://saturnids.spicenet.net/sonario/develop081125/develop081125-mysql.html You have to login - if D.Lila is still there, he has the required info. Here's the transcript as of today: [don@number11 ~]$ firefox & [1] 31759 [don@number11 ~]$ failed to create drawable java version "1.6.0_22" OpenJDK Runtime Environment (IcedTea6 1.10.3) (fedora-59.1.10.3.fc15-i386) OpenJDK Client VM (build 20.0-b11, mixed mode) system look and feel class: com.sun.java.swing.plaf.gtk.GTKLookAndFeel free: 10524 allocated: 18984 max: 496960 total free memory: 488500 hostname saturn.spicenet.net port 443 javax.net.ssl.SSLException: java.security.AccessControlException: access denied (java.security.AllPermission <all permissions> <all actions>) at sun.security.ssl.Alerts.getSSLException(Alerts.java:208) at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1665) at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1628) at sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1611) at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1192) at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1169) at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:440) at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185) at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1139) at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:254) at LoginFormPanel.cmdOK_ClickMYSQL(LoginFormPanel.java:259) at LoginFormPanel.cmdOK_Click(LoginFormPanel.java:237) at LoginFormPanel$1.construct(LoginFormPanel.java:495) at SwingWorker$2.run(SwingWorker.java:107) at java.lang.Thread.run(Thread.java:679) Caused by: java.security.AccessControlException: access denied (java.security.AllPermission <all permissions> <all actions>) at java.security.AccessControlContext.checkPermission(AccessControlContext.java:393) at java.security.AccessController.checkPermission(AccessController.java:553) at java.lang.SecurityManager.checkPermission(SecurityManager.java:549) at net.sourceforge.jnlp.runtime.JNLPSecurityManager.checkPermission(JNLPSecurityManager.java:261) at net.sourceforge.jnlp.runtime.JNLPRuntime.getSecurityDialogHandler(JNLPRuntime.java:404) at net.sourceforge.jnlp.security.SecurityWarning.getUserResponse(SecurityWarning.java:298) at net.sourceforge.jnlp.security.SecurityWarning.showCertWarningDialog(SecurityWarning.java:196) at net.sourceforge.jnlp.security.VariableX509TrustManager.askUser(VariableX509TrustManager.java:381) at net.sourceforge.jnlp.security.VariableX509TrustManager.checkServerTrusted(VariableX509TrustManager.java:245) at net.sourceforge.jnlp.security.VariableX509TrustManager.checkServerTrusted(VariableX509TrustManager.java:194) at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1144) at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:154) at sun.security.ssl.Handshaker.processLoop(Handshaker.java:610) at sun.security.ssl.Handshaker.process_record(Handshaker.java:546) at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:913) at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1158) at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1185) ... 10 more URL connection failed - try direct Thread[Thread-18,6,http://saturnids.spicenet.net/sonario/develop081125/] Connecting to server... driver mysql driverport 3307 driverhost dsn user ddevelop080401 pass a29e69f7506c78c56ce5f4f28a6fe591 connect to url jdbc:mysql://saturn.spicenet.net:3307/develop080401?user=ddevelop080401&password=a29e69f7506c78c56ce5f4f28a6fe591&useSSL=true&requireSSL=true&requireSSLcert=false&dontTrackOpenResources=true&dumpQueriesOnException=true&noAccessToProcedureBodies=true com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure Last packet sent to the server was 1 ms ago. at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:532) at com.mysql.jdbc.Util.handleNewInstance(Util.java:406) at com.mysql.jdbc.SQLError.createCommunicationsException(SQLError.java:1074) at com.mysql.jdbc.ConnectionImpl.createNewIO(ConnectionImpl.java:2104) at com.mysql.jdbc.ConnectionImpl.<init>(ConnectionImpl.java:729) at com.mysql.jdbc.JDBC4Connection.<init>(JDBC4Connection.java:46) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:532) at com.mysql.jdbc.Util.handleNewInstance(Util.java:406) at com.mysql.jdbc.ConnectionImpl.getInstance(ConnectionImpl.java:302) at com.mysql.jdbc.NonRegisteringDriver.connect(NonRegisteringDriver.java:283) at java.sql.DriverManager.getConnection(DriverManager.java:620) at java.sql.DriverManager.getConnection(DriverManager.java:222) at StoredProc.registerConnection(StoredProc.java:583) at LoginFormPanel.cmdOK_ClickMYSQL(LoginFormPanel.java:325) com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure Last packet sent to the server was 1 ms ago. [don@number11 ~]$ (In reply to comment #1) > The url for this is > http://saturnids.spicenet.net/sonario/develop081125/develop081125-mysql.html > You have to login - if D.Lila is still there, he has the required info. I think I have a fix [1], but I would like to test it. Can I get a temporary login? [1] http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2011-September/015689.html (In reply to comment #1) > The url for this is > http://saturnids.spicenet.net/sonario/develop081125/develop081125-mysql.html > You have to login - if D.Lila is still there, he has the required info. I cant reproduce the issue... I tried with the fedora packages, icedtea-web 1.0, 1.1 and HEAD and the applet works fine (and I can log in) with all of them. Is an error still happening on your end? Interesting, it's now working for me too. Perhaps due to the now correctly signed jar? (In reply to comment #5) > Interesting, it's now working for me too. > Perhaps due to the now correctly signed jar? Very likely. That said, this should have worked without requiring code to be signed. So I am going to close this bug, but commit the fix I posted above anyway. Perhaps I should revert to the incorrectly signed jar, verify that I get the problem, and then let you test your new fix in that version? (In reply to comment #7) > Perhaps I should revert to the incorrectly signed jar, verify that I get the > problem, and then let you test your new fix in that version? Could you? That would be great! Thanks! Try now. (That was harder than I expected. Just re-signing wasn't good enough.) With the fix applied upstream, I dont get the javax.net.ssl.SSLException: java.security.AccessControlException: access denied (java.security.AllPermission <all permissions> <all actions>) But I do run into the other exception in the original stack trace: com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure Last packet sent to the server was 0 ms ago. at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:532) at com.mysql.jdbc.Util.handleNewInstance(Util.java:406) at com.mysql.jdbc.SQLError.createCommunicationsException(SQLError.java:1074) at com.mysql.jdbc.ConnectionImpl.createNewIO(ConnectionImpl.java:2104) at com.mysql.jdbc.ConnectionImpl.<init>(ConnectionImpl.java:729) at com.mysql.jdbc.JDBC4Connection.<init>(JDBC4Connection.java:46) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:532) at com.mysql.jdbc.Util.handleNewInstance(Util.java:406) at com.mysql.jdbc.ConnectionImpl.getInstance(ConnectionImpl.java:302) at com.mysql.jdbc.NonRegisteringDriver.connect(NonRegisteringDriver.java:283) at java.sql.DriverManager.getConnection(DriverManager.java:620) at java.sql.DriverManager.getConnection(DriverManager.java:222) at StoredProc.registerConnection(StoredProc.java:583) at LoginFormPanel.cmdOK_ClickMYSQL(LoginFormPanel.java:325) com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure There is no 'cause' field in the stack trace to I cant tell what's causing this. Permissions problem would be my guess. at StoredProc.registerConnection(StoredProc.java:583) That line is conn = DriverManager.getConnection(url); which is trying to get a mysql connection. I suppose the first thing to do is try it again, since internet connections do sometimes fail. Perhaps you're behind a firewall that prevents this connection? Do you see this stuff? Connecting to server... driver mysql driverport 3307 driverhost dsn user ddevelop080401 pass ... connect to url jdbc:mysql://saturn.spicenet.net:3307/develop080401?user=ddevelop080401... You might try recording packets - if you're sending to port 3307 and not getting anything back then the problem is probably in the network (a firewall I'd guess) rather than in java. It occurs to me that you did manage to run without trouble earlier with the fixed jar. If you're running from the same place now, it's probably not a firewall problem. We might end up having to look at the mysql driver code. Um... I would (In reply to comment #12) > It occurs to me that you did manage to run without trouble earlier with the > fixed jar. If you're running from the same place now, it's probably not a > firewall problem. We might end up having to look at the mysql driver code. Yes, I was running from the same location both times. I am afraid I dont have too much time right now to look into this. Especially given that the problem was fixed by signing all the jars (as opposed to just some of them). One thing I don't understand: Since individual files are signed rather than the jar as a whole, java should act as if the untrusted (unsigned) files don't exist, not act as if the entire jar is invalid, right? My understanding is that the offending file in this case was optional. In that sense, at least, this issue still seems like a bug. Should I reopen it (or open another one) on that basis? (In reply to comment #14) > One thing I don't understand: > Since individual files are signed rather than the jar as a whole, java should > act as if the untrusted (unsigned) files don't exist, not act as if the entire > jar is invalid, right? The implementation of resource/jar loading limits our ability to filter what is visible. In fact there is no concept of a filter. Java can either see all the contents of a jar, or it cant see the jar file at all. I am not sure if it is possible to 'fix' class loading to make this work. It is also worth noting that security is vital. I would rather javaws halted on jars containing unsigned content than risk unsigned/malicious files sneaking through. > My understanding is that the offending file in this > case was optional. In that sense, at least, this issue still seems like a bug. > Should I reopen it (or open another one) on that basis? Feel free to open a bug. I cant say if/when a fix might be possible. I guess you're describing details of JVM about which I know little. The idea of accepting or rejecting an entire jar as a unit makes sense if the jar is signed as a unit - maybe that's why I imagined that it was signed as a unit. In terms of security, I see no loss from accepting the files that are correctly signed and not those that are not. The signature is supposed to be an adequate test for trusting anything. It sounds to me like anyone should be able to extract the parts of a jar that are signed and repackage them into a new jar, which will then be accepted cause everything in it is signed. Is that correct? In terms of new bugs - if this is a problem in the java spec then is there some other place to complain? Or is it still appropriate to file it as a bug here? (In reply to comment #16) > In terms of security, I see no loss from accepting the files that are correctly > signed and not those that are not. The signature is supposed to be an adequate > test for trusting anything. It sounds to me like anyone should be able to > extract the parts of a jar that are signed and repackage them into a new jar, > which will then be accepted cause everything in it is signed. Is that correct? Extracting and repackaging will not correctly update the MANIFEST.MF file (which contains a hash of every signed file). The signature SF files also contain a hash of the manifest. I am not sure if this jar will work or not, but it certainly is not transparent. Someone looking at it can tell it was extracted from another jar. > In terms of new bugs - if this is a problem in the java spec then is there some > other place to complain? Or is it still appropriate to file it as a bug here? You can file a bug here, or at icedtea: http://icedtea.classpath.org/bugzilla/enter_bug.cgi?product=IcedTea But the folks who work on the java spec are more likely to see a bug if it is filed at: http://bugreport.sun.com/bugreport/ new bug reported (not available for a few days) http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7096008 Maybe that's where I should have sent the indexed color bug. Hmm, I've just created an extra url, http://saturnids.spicenet.net/sonario/develop081125/develop081125-mysql-bad.html and changed http://saturnids.spicenet.net/sonario/develop081125/develop081125-mysql.html with the idea that the -bad version would be available for debugging and the other one could be used normally. The only difference is that -bad requires mysql-connector-java-5.1.5-bin-bad.jar instead of mysql-connector-java-5.1.5-bin.jar with the difference between those two being that the bad one has INDEX.LIST unsigned. I expected the good version to run and the bad one not to. However, what I see now in fc15 is that neither runs. In both cases there is nothing sent to the mysql server, I presume due to some access restriction. Can you see what's going on here? Have I done something stupid? |