Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

EXPERIMENTAL: Remove SecurityManager #1353

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

rPraml
Copy link
Contributor

@rPraml rPraml commented Jul 6, 2023

Hello, I want to discuss, if it is already time to remove the dependency to SecurityManager from Rhino.

There was already a discussion, where I was involved: #972

and the last days I found some time to update our fork.

Why should we remove the dependency to securityManager

  • because it is deprecated since Java 9
  • because it is deprecated for removal since java 17

Why shouldn't we remove it

  • because there are JVMs that still have an active security-manager
  • because people rely on a complex security policy, when executing javascript (at least we did this, but we removed it from our application code, because we realized that the concept is very hard to understand and there is no 100% security)

This PR is radical and removes all code pieces, that relate to SecurityManager.

(Note: I've made an earlier PR, where I moved all stuff to a "SecurityBridge". See: #1068)

Maybe you can provide some feedback, what will be a good way to go here?

Copy link
Contributor Author

@rPraml rPraml left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This PR contains some thoughts. Maybe more code can be removed/simplified (like SecureCaller)

@@ -132,7 +101,7 @@ public synchronized void setCachingEnabled(boolean enabled) {
}

/** @return a map from classes to associated JavaMembers objects */
Map<CacheKey, JavaMembers> getClassCacheMap() {
Map<Class, JavaMembers> getClassCacheMap() {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No security context -> We can revert this change #1019

@@ -23,8 +23,7 @@ public Class<?> defineClass(String name, byte[] data) {
// Use our own protection domain for the generated classes.
// TODO: we might want to use a separate protection domain for classes
// compiled from scripts, based on where the script was loaded from.
return super.defineClass(
name, data, 0, data.length, SecurityUtilities.getProtectionDomain(getClass()));
return super.defineClass(name, data, 0, data.length, getClass().getProtectionDomain());
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CHECKME: Would we need a protectionDomain at all?

if (protectionDomain == null) {
protectionDomain = JavaAdapter.class.getProtectionDomain();
}
ProtectionDomain protectionDomain = JavaAdapter.class.getProtectionDomain();
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CHECKME: can this be simplified?

@@ -319,8 +318,7 @@ private void discoverAccessibleMethods(
if (isPublic(mods) || isProtected(mods) || includePrivate) {
MethodSignature sig = new MethodSignature(method);
if (!map.containsKey(sig)) {
if (includePrivate && !method.isAccessible())
method.setAccessible(true);
VMBridge.instance.tryToMakeAccessible(method);
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CHECKME: Do we need a VMBridge for java 11/17?

@gbrail
Copy link
Collaborator

gbrail commented Aug 4, 2023

I think that we should do this after the 1.7.15 release -- at that point I want to reorganize the source files (git seems to be smart enough to make that less of a nightmare), upgrade the build to require Java 11 minimum, and then this can be one of the first things that we address.

@p-bakker p-bakker added the Java Compatibility Issues related to Rhino being compatible to (new) Java releases label Oct 25, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Java Compatibility Issues related to Rhino being compatible to (new) Java releases
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants