How to disable the Java Security Manager
The Java Security Manager is a security component of the Java Runtime Environment (JRE) that controls the permissions granted to the code running within the Java Virtual Machine (JVM). When using Java 8, Data Collector includes a Java Security Manager that is enabled by default.
The Security Manager works by maintaining a security policy file that defines the permissions and restrictions for various types of Java code, such as applets, Java Web Start applications, and server-side Java applications. When a Java application attempts to access system resources, such as files, network sockets, or system properties, the Security Manager consults the security policy file to determine whether the access is allowed or not.
If you are getting errors similar to this, you may find it is related to the Java Security Manager;
"errorStackTrace": "com.streamsets.pipeline.api.base.OnRecordErrorException: SCRIPTING_04 - Script sent record to error: java.security.AccessControlException: access denied (\"java.lang.RuntimePermission\" \"accessClassInPackage.jdk.nashorn.internal.ir\")\n\tat com.streamsets.pipeline.stage.processor.scripting.ScriptingProcessorInitDestroyBindings$Err.write(ScriptingProcessorInitDestroyBindings.java:48)\n\tat
The file which you can permission different java codebases is $SDC_CONF/sdc-security.policy
Some of the default permissions in the sdc-security.policy file
Typically, if you are using custom code in any of the applicable stages in the pipeline, you will need to grant permission to the codebase in this file. Then when the pipeline runs and that stage is being executed, the Java Security Manager will know that this code has been granted permission and it should run.
However, sometimes it may still be blocked by the Java Security Manager. We can disable the Java Security Manager if it’s causing more harm than help. You can do it temporarily for testing purposes to see if this resolves the issue, or permanently if this resolves the issue.
This might sound scary, but in reality, it is not. The main “risk” is that any stage could potentially perform any operation, which puts the onus on the customer to review the scripting stages much more carefully. The rest of the stages are provided by SteamSets and thus, is trusted code (even though we isolate the code just to be sure). It doesn’t open any other security issues, and in fact, the Java community is actually moving away from the security manager, without any clear replacement.
Here are two links where you can read about the removal and deprecation of the Security Manager;
https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/SecurityManager.html
To disable the Java Security Manager
Open $SDC/libexec/sdc-enh.sh
Here you have two options;
1 - change the ‘true’ to ‘false’ on the following line
OR
2 - if you don’t want to edit the default config, simply copy and paste the following command to the bottom of the file;
export SDC_SECURITY_MANAGER_ENABLED="false"Then save the changes, and restart the SDC.
Disabling the JSM using Cloudera
1 - Navigate to the sdc-env.sh file in the Cloudera Manager, and add the following line;
export SDC_SECURITY_MANAGER_ENABLED="false"2 - Save the changes and restart the SDC.
If you want to verify that the JSM has been disabled, do the following;
1 - Run command jcmd to identify the PID of your java process (you can use any other technique you wish, like ps).
2 - Run the following command, replacing <PID> with the PID above; jcmd <PID> VM.command_line
3 - Check that you see the following string in the output: -D java.security.manager
If you see it, the Security Manager is enabled. If not, then it has been disabled successfully.