SecurityServicesFeature unregisters Providers too early? #3664
Comments
|
cc @gradinac |
oubidar-Abderrahim
assigned gradinac and oubidar-Abderrahim and unassigned oubidar-Abderrahim
|
@gradinac did you have the chance to take a look at this? I am willing to work on a fix for it, but I would like to get some feedback about my claims from you first. Thanks |
|
Hey @zakkak! Sorry for a late answer on this. The security services feature currently automatically registers only services that follow the JCA. Unfortunately, that doesn't seem to be the case for the SASL provider, but, we still would want to support it. The proposed changes seem good - though we will most likely encounter this again in the future - perhaps we could keep these special methods in a set somewhere and iterate over them when checking if we should register a reachability handler. One thing that confused me a bit is that |
Hi @gradinac, as mentioned in the description:
Explaining in more detail and links to the corresponding code below: The reproducer invokes Applying diff --git a/substratevm/src/com.oracle.svm.core/src/com/oracle/svm/core/jdk/SecuritySubstitutions.java b/substratevm/src/com.oracle.svm.core/src/com/oracle/svm/core/jdk/SecuritySubstitutions.java
index 03c931b8c9b..a2032223019 100644
--- a/substratevm/src/com.oracle.svm.core/src/com/oracle/svm/core/jdk/SecuritySubstitutions.java
+++ b/substratevm/src/com.oracle.svm.core/src/com/oracle/svm/core/jdk/SecuritySubstitutions.java
@@ -680,7 +680,8 @@ final class Target_sun_security_jca_Providers {
@Override
public Object transform(MetaAccessProvider metaAccess, ResolvedJavaField original, ResolvedJavaField annotated, Object receiver, Object originalValue) {
ProviderList originalProviderList = (ProviderList) originalValue;
- return SecurityProvidersFilter.instance().cleanUnregisteredProviders(originalProviderList);
+ return originalProviderList;
+// return SecurityProvidersFilter.instance().cleanUnregisteredProviders(originalProviderList);
}
}
}
diff --git a/substratevm/src/com.oracle.svm.hosted/src/com/oracle/svm/hosted/SecurityServicesFeature.java b/substratevm/src/com.oracle.svm.hosted/src/com/oracle/svm/hosted/SecurityServicesFeature.java
index 3f6e23b3ec3..32305919342 100644
--- a/substratevm/src/com.oracle.svm.hosted/src/com/oracle/svm/hosted/SecurityServicesFeature.java
+++ b/substratevm/src/com.oracle.svm.hosted/src/com/oracle/svm/hosted/SecurityServicesFeature.java
@@ -538,6 +538,9 @@ public class SecurityServicesFeature extends JNIRegistrationUtil implements Feat
checkGetInstanceMethod(method);
/* The handler will be executed only once if any of the methods is triggered. */
access.registerMethodOverrideReachabilityHandler(handler, method);
+ } else if (method.getName().equals("createSaslClient") || method.getName().equals("createSaslServer")) {
+ /* The handler will be executed only once if any of the methods is triggered. */
+ access.registerMethodOverrideReachabilityHandler(handler, method);
}
}
}makes it work, confirming(?) my theory. |
|
@zakkak Thank you for a detailed explanation! Upon investigating it a bit further, it seems like Graal indeed doesn't see the I've created a PR that should fix the automatic registration of this provider: #4279 |
|
Thank you, adding this on 22.2.0-r11 solves the problem with jboss remoting3 ( 5.0.18.Final ) failed :Authentication failed: none of the mechanisms presented by the server (DIGEST-MD5) are supported source: null |
Describe the issue
SecurityServicesFeature fails to automatically register SunSASL provider and requires the addition of
-H:AdditionalSecurityProviders=com.sun.security.sasl.Providerdespite being specified in the JCA.Steps to reproduce the issue
Describe GraalVM and your environment:
More details
Compiling with
-H:+TraceSecurityServicesand without-H:AdditionalSecurityProviders=com.sun.security.sasl.Providerresults in the following report:While adding
-H:AdditionalSecurityProviders=com.sun.security.sasl.Providerresults in:i.e, it appears that
javax.crypto.Cipher.getInstance(java.lang.String)becomes reachable only when-H:AdditionalSecurityProviders=com.sun.security.sasl.Provideris used. Adding-H:+PrintAnalysisCallTreewe indeed see that when-H:AdditionalSecurityProviders=com.sun.security.sasl.Provideris used the following methods become reachable:resulting in the automatic registration of Sun and SunJCE. Not of SunSasl though which only ends up in the image because we explicitly added it as an additional security provider, indicating another possible issue. Looking at
com.oracle.svm.hosted.SecurityServicesFeature#knownServiceswe observe that all classes except forSaslClientFactoryandSaslServerFactoryprovide the methodgetInstace, whileSaslClientFactoryandSaslServerFactoryprovidecreateSaslClientandcreateSaslServerrespectively. As a result in order to automatically register Sasl services I believe we should register handlers for those methods like we do forgetInstance.The following prototype of the above :
results in the following report which indicates that SunSASL is being registered due to the analysis and not only due to the explicit addition of it through
-H:AdditionalSecurityProviders=com.sun.security.sasl.Providerwhich is still required to register SunSasl even after the patch:As
javax.security.sasl.Sasl#createSaslClientandjavax.security.sasl.Sasl#createSaslServerinvokeSecurity.getProviders(String)my intuition is that in the absence of-H:AdditionalSecurityProviders=com.sun.security.sasl.Providergraal doesn't return the SunSasl provider and thusjavax.security.sasl.SaslClientFactory#createSaslClientandjavax.security.sasl.SaslServerFactory#createSaslServerare not seen as reachable and thus SunSasl is not getting registered. Does this make sense?The text was updated successfully, but these errors were encountered: