StandardEnvironment's system environment access produces warning with stacktrace on WebSphere [SPR-11297] #15921
Comments
|
Stéphane Nicoll commented The issue here is slightly different even though it is closely related. It seems the security policy of your environment forbids any call to From what I can see here, the error you get is generated by WAS as the security policy is violated (i.e. the error is not thrown from the application itself). Is this an annoying error in the logs or does it prevent your application to deploy? |
|
Juergen Hoeller commented The root of the problem is that we cannot find out whether getenv() is supported other than through actually calling the method. There seems to be no way to 'softly' check a permission with a SecurityManager, other than the regular checkPermission() call that leads to the warn log stacktrace above. Otherwise we could actively avoid that scenario. As for StandardEnvironment, it falls back to system properties and system environment entries if it cannot resolve an environment property. This is more general and lower-level than the Spring application context and its use of an expression language; it is architecturally hard to override this through beans defined at the application context level. In any case, we'll see what we can do here... Juergen |
|
Sharath commented Stephane Nicol: It is ana annoying error in the logs and our load test team believes it has something to do with performance. We tried to convince them that is not related to performance but they want this to be removed so we upgraded Spring from 3.0.2 to 3.2.5 but still we see this. Juergen Hoeller: Is there any alternate we can use to suppress this error? We tried the following also and still we see the error <bean class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer"> If we try upgrading to 3.2.7 will this go? Thanks |
|
Juergen Hoeller commented We're going to address this with 3.2.7 in some form. It's scheduled for release on Jan 23, so there's still some time to go. If there's no better way to do it, we might define some special property that turns off default system environment access. However, that property might have to be a system property in its own right... Is WebSphere restrictive towards JVM system properties as well, or just towards process environment variables? Juergen |
|
Sharath commented Thanks for the update will wait for the 3.2.7 release. |
|
Juergen Hoeller commented The only way to suppress these warnings is in WebSphere's configuration: The IBM docs talk about a "com.ibm.ws.security.core.SecurityManager=all=enabled" setting that triggers such stacktraces for AccessControlExceptions. However, that setting seems to be off by default. Are you, by any chance, explicitly activating it in your server configuration? Alternatively, we could offer a "spring.system.getenv" system property that can be explicitly set to "false" to suppress any kind of getenv access. However, you'd have to specify that as a system property for your server VM, i.e. through a -D command line argument or equivalent thereof in WebSphere's server configuration. Would that be possible? Juergen |
|
Sharath commented We cannot change the Websphere's configuration but can request to add a System property "spring.system.getenv". Let us know if we need to add that system property and what should be its value. Thanks |
|
Juergen Hoeller commented I'm implementing it as "spring.getenv.ignore" now, with a value of "true" deactivating any kind of System.getenv access in Spring (in AbstractEnvironment as well as the PlaceholderConfigurers, through a single flag). This is analogous to the recently introduced "spring.beaninfo.ignore" property (see #13653). Juergen |
|
Juergen Hoeller commented This will be available in the upcoming 3.2.7 and 4.0.1 snapshots now (see http://projects.spring.io/spring-framework/ for Maven coordinates). Please give it a try and let me know whether it works for you... Note that, when setting the "spring.getenv.ignore" flag to "true", you don't have to define a "systemEnvironment" bean anymore, since the flag replaces the corresponding default bean with an empty Map anyway. Juergen |
|
Sharath commented Thanks Juergen for the update. Can I download the jars directly so that we can try? We dont use maven. Thanks |
|
Juergen Hoeller commented You can download the jars straight from the Maven repo, actually: http://repo.spring.io/snapshot/org/springframework/spring-core/3.2.7.BUILD-SNAPSHOT/ http://repo.spring.io/snapshot/org/springframework/spring-beans/3.2.7.BUILD-SNAPSHOT/ You'll definitely need spring-core for the AbstractEnvironment changes, and spring-beans wouldn't hurt if you're using PropertyPlaceholderConfigurer as well. |
|
Sharath commented Hi Juergen, I have tried the 3.2.7 snapshot but still we are getting the errors. I have included both spring-core and spring-beans jars. Do we need to try any different jar? Permission: Code: Stack Trace: java.security.AccessControlException: Access denied (java.lang.RuntimePermission getenv.*) |
|
Sharath commented Still getting the same error even if we are using the 3.2.7 snapshot jars. |
|
Juergen Hoeller commented There is an explicit check for "true".equalsIgnoreCase(System.getProperty("spring.getenv.ignore")) right before that System.getenv() call, falling back to an empty Map in that case... So if you're still getting the AccessControlException, then accessing the system property "spring.getenv.ignore" didn't work. Can you please double-check whether the system property is properly set? You could do a programmatic System.getProperty("spring.getenv.ignore") call somewhere in your startup code, or even in a JSP expression, and see what it returns... Juergen |
|
Sharath commented I overlooked setting "spring.getenv.ignore" flag to "true", thought it would be true by default. We need to request to set the property which will take some time... We dont have direct access to specify the property. We will request and try it again.. Thanks |
|
Vijendra Kulhade commented I am also facing the same issue. I have tried to set the systemProperty "spring.getenv.ignore" during start up of my application. Thanks |
|
Stéphane Nicoll commented Vijendra, the property is resolved early in the process of creating the application context so setting the property in your own bean won't have any effect ("too late"). Yes, this should be set at VM level. Thanks. |
|
Juergen Hoeller commented Sharath, have you had a chance to try the system property? Any success with the log entries disappearing? Juergen |
|
Sharath commented Hi Juergen, I raised a case with our infra team to add the system property but they declined it and said they cannot add the property due to the restrictions. Is there any other way to avoid the log entries? If there is no other way then we need to live with these log entries... Thanks |
|
Vijendra Kulhade commented Same happened with me also. Infra team declined to add the property. |
|
Juergen Hoeller commented Alright, I'll try to find an alternative way for you guys to set this flag - in time for tomorrow's 4.0.1 and 3.2.7 releases. Juergen |
|
Sharath commented Thanks Juergen, will wait for the alternate. |
|
Juergen Hoeller commented I've introduced support for a local SpringProperties class, allowing to set properties such as "spring.getenv.ignore" and "spring.beaninfo.ignore" in a local way, that is, without having to touch JVM system properties. This can either be done through programmatic SpringProperties.setProperty/setFlag calls or through specifying the properties in a "spring.properties" file in the root of the classpath. Note that the file needs to live in the same ClassLoader as the Spring jars! If such a property isn't found in our local SpringProperties, we'll still fall back to checking JVM-level system properties. This is available in the latest 4.0.1 and 3.2.7 snapshots now. Please give it a try... Note that those two releases are planned to go public on Monday, January 27th. Juergen |
|
Pavan commented Juergen -> We have developed an Application on Grails (Uses Spring V 3.1.4 & Hibernate)and trying to deploy the same to WAS 7.0 in CISCO. We have been encountering the same Error as stated above by Sharath , however after implementing the Fix which you guys have done, we have overcome that issue. Thanks so much for that. However , we are facing another issue as stated below which is failing our application to load. Permission: setContextClassLoader : Access denied (java.lang.RuntimePermission setContextClassLoader) Code: org.codehaus.groovy.grails.orm.hibernate.ConfigurableLocalSessionFactoryBean in {file:/opt/httpd/root/apps/dmsdlc/ibm7/ccix-dev-ear/oak-0.1.war/WEB-INF/lib/grails-hibernate-2.2.4.jar} //Pavan |
|
Juergen Hoeller commented Hi Pavan, Glad to hear that the fix works for you! Out of curiosity, are you setting "spring.getenv.ignore" through a system property or in a spring.properties file? As for the setContextClassLoader issue, you'll have to report that to Grails since it's in the Grails codebase: http://jira.grails.org/browse/GRAILS Juergen |
|
Pavan commented Hi Juergen -> We are setting the properties through spring.properties file only. We have taken the patch which you have uploaded. Yeah , CCIX which is CISCO's Deployment Environment has lot of policy restrictions and we need to open case with Grails as well on the same. sincerely Appreciate your Support. Best Regards |
|
Juergen Hoeller commented Sharath, Vijendra, Have you had a chance to give a recent 3.2.7 snapshot a try? Would be good to know whether the spring.properties approach works for you as well... We're planning to release tomorrow European evening now, so if you keep having remaining issues, we should still be able to incorporate your feedback in time for 4.0.1/3.2.7. Juergen |
|
Sharath commented I did not get a chance to try, I will try today and update you. Thanks |
|
Vijendra Kulhade commented Hi , I didn't get time to check. Thanks |
|
Juergen Hoeller commented Thanks for the timely response! Basically just use the latest 3.2.7 snapshot and put a "spring.properties" file in the root of your classpath (the same classpath that the Spring jars are in), with the following line as the file's content: spring.getenv.ignore=true That should do the trick. |
|
Vijendra Kulhade commented Hi Juergen, I kept the spring.properties file in the same root classpath where spring-core is available. Thanks |
|
Juergen Hoeller commented The spring.properties file needs to be in the root of an actual classpath directory, e.g. WEB-INF/classes - not in a jar directory such as WEB-INF/lib. Did you maybe fall into that trap? You should see the following log entry at info level: "Found 'spring.properties' file in local classpath" Hope that helps, Juergen |
|
Vijendra Kulhade commented Thanks Juergen, this worked. Everything is fine now. |
|
Juergen Hoeller commented Good to hear, Vijendra! That makes me feel better about making this generally available tomorrow :-) Juergen |
|
Sharath commented Thanks Juergen, it is working with the spring.properties and I don't see any exceptions now. Thanks |
|
Juergen Hoeller commented Sharath, thanks a lot for the timely response. This is really good to know! Juergen |
spring-projects-issues
added
type: bug
Sharath opened SPR-11297 and commented
We are using Spring 3.2.5 on WAS7.0
We have the following beans but still we are getting error, can you suggest any alternate.
Current Java 2 Security policy reported a potential violation of Java 2 Security Permission. Refer to the InfoCenter for further information.
Permission:
Code:
Stack Trace:
java.security.AccessControlException: Access denied (java.lang.RuntimePermission getenv.*)
at java.security.AccessController.throwACE(AccessController.java:100)
at java.security.AccessController.checkPermission(AccessController.java:174)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:544)
at com.ibm.ws.security.core.SecurityManager.checkPermission(SecurityManager.java:206)
at java.lang.System.getenv(System.java:688)
at org.springframework.core.env.AbstractEnvironment.getSystemEnvironment(AbstractEnvironment.java:348)
at org.springframework.core.env.StandardEnvironment.customizePropertySources(StandardEnvironment.java:79)
at org.springframework.web.context.support.StandardServletEnvironment.customizePropertySources(StandardServletEnvironment.java:90)
at org.springframework.core.env.AbstractEnvironment.<init>(AbstractEnvironment.java:114)
at org.springframework.web.context.support.StandardServletEnvironment.<init>(StandardServletEnvironment.java:44)
at org.springframework.web.context.support.AbstractRefreshableWebApplicationContext.createEnvironment(AbstractRefreshableWebApplicationContext.java:156)
at org.springframework.context.support.AbstractApplicationContext.getEnvironment(AbstractApplicationContext.java:288)
at org.springframework.context.support.AbstractRefreshableConfigApplicationContext.resolvePath(AbstractRefreshableConfigApplicationContext.java:122)
at org.springframework.context.support.AbstractRefreshableConfigApplicationContext.setConfigLocations(AbstractRefreshableConfigApplicationContext.java:80)
at org.springframework.context.support.AbstractRefreshableConfigApplicationContext.setConfigLocation(AbstractRefreshableConfigApplicationContext.java:68)
at org.springframework.web.context.ContextLoader.configureAndRefreshWebApplicationContext(ContextLoader.java:386)
at org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:294)
at org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:112)
at com.ibm.ws.webcontainer.webapp.WebApp.notifyServletContextCreated(WebApp.java:1718)
at com.ibm.ws.webcontainer.webapp.WebApp.commonInitializationFinish(WebApp.java:385)
at com.ibm.ws.webcontainer.webapp.WebAppImpl.initialize(WebAppImpl.java:299)
at com.ibm.ws.webcontainer.webapp.WebGroupImpl.addWebApplication(WebGroupImpl.java:100)
at com.ibm.ws.webcontainer.VirtualHostImpl.addWebApplication(VirtualHostImpl.java:166)
at com.ibm.ws.webcontainer.WSWebContainer.addWebApp(WSWebContainer.java:732)
at com.ibm.ws.webcontainer.WSWebContainer.addWebApplication(WSWebContainer.java:617)
at com.ibm.ws.webcontainer.component.WebContainerImpl.install(WebContainerImpl.java:376)
at com.ibm.ws.webcontainer.component.WebContainerImpl.start(WebContainerImpl.java:668)
at com.ibm.ws.runtime.component.ApplicationMgrImpl.start(ApplicationMgrImpl.java:1128)
at com.ibm.ws.runtime.component.DeployedApplicationImpl.fireDeployedObjectStart(DeployedApplicationImpl.java:1319)
at com.ibm.ws.runtime.component.DeployedModuleImpl.start(DeployedModuleImpl.java:611)
at com.ibm.ws.runtime.component.DeployedApplicationImpl.start(DeployedApplicationImpl.java:944)
at com.ibm.ws.runtime.component.ApplicationMgrImpl.startApplication(ApplicationMgrImpl.java:741)
at com.ibm.ws.runtime.component.ApplicationMgrImpl$3.run(ApplicationMgrImpl.java:2056)
at com.ibm.ws.security.auth.ContextManagerImpl.runAs(ContextManagerImpl.java:5395)
at com.ibm.ws.security.auth.ContextManagerImpl.runAsSystem(ContextManagerImpl.java:5483)
at com.ibm.ws.security.core.SecurityContext.runAsSystem(SecurityContext.java:255)
at com.ibm.ws.runtime.component.ApplicationMgrImpl.start(ApplicationMgrImpl.java:2061)
at com.ibm.ws.runtime.component.CompositionUnitMgrImpl.start(CompositionUnitMgrImpl.java:389)
at com.ibm.ws.runtime.component.CompositionUnitImpl.start(CompositionUnitImpl.java:123)
at com.ibm.ws.runtime.component.CompositionUnitMgrImpl.start(CompositionUnitMgrImpl.java:332)
at com.ibm.ws.runtime.component.CompositionUnitMgrImpl.access$300(CompositionUnitMgrImpl.java:117)
at com.ibm.ws.runtime.component.CompositionUnitMgrImpl$CUInitializer.run(CompositionUnitMgrImpl.java:899)
at com.ibm.wsspi.runtime.component.WsComponentImpl$_AsynchInitializer.run(WsComponentImpl.java:496)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1656)
Affects: 3.2.5
Issue Links:
Backported to: 3.2.7
0 votes, 7 watchers
The text was updated successfully, but these errors were encountered: