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

[WFLY-15652] load InitialContextFactory class within doPrivileged block #14895

Closed
wants to merge 1 commit into from

Conversation

istudens
Copy link
Contributor

@github-actions github-actions bot added the deps-ok Dependencies have been checked, and there are no significant changes label Nov 12, 2021
@istudens
Copy link
Contributor Author

@darranl could you review this please? see a comment in the jira. thanks

final Constructor<javax.naming.spi.InitialContextFactory> factoryClassConstructor;
if (WildFlySecurityManager.isChecking()) {
factoryClassConstructor = AccessController.doPrivileged((PrivilegedExceptionAction<Constructor<javax.naming.spi.InitialContextFactory>>) () -> {
final Class<?> factoryClass = Class.forName(factoryClassName, false, classLoader);
Copy link
Contributor

Choose a reason for hiding this comment

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

It is not enough to request changes on this PR but IMO I find it better to split all of the common code out, in this case it could just be a static method.

Where code like this is duplicated there is a risk in the future that the two get out of sync so bugs only occur in one case or the other.

@darranl
Copy link
Contributor

darranl commented Nov 24, 2021

Regarding the actual changes, I have some concerns that this may not be appropriate as this now means the caller can load any classes without their own protection domain being included in the permission check - I think the existing behaviour that the callers protections domain is needed for loading classes specified in the properties is correct.

@istudens
Copy link
Contributor Author

@darranl Does it mean the Jira should be closed as Won'tFix then?

@darranl
Copy link
Contributor

darranl commented Dec 16, 2021

@istudens yes I think we should close as wont fix

@darranl darranl closed this Jan 22, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
deps-ok Dependencies have been checked, and there are no significant changes
Projects
None yet
2 participants