Bug 927930

After hacking properties I reach:
+++
org.apache.jasper.JasperException: java.security.AccessControlException: access denied (java.io.FilePermission /var/lib/tomcat6/webapps/smtest/localhost/smtest/WEB-INF/web.xml read)
+++
we use symlinks and java probably don't handle that well...

Looks like /usr/sbin/tomcat6 (line 51) has an extraneous '=' in assigning java.security.policy:

    -Djava.security.manager \
    -Djava.security.policy=="${CATALINA_BASE}/conf/catalina.policy" \

Removing the extra '=' allows Tomcat to start up with the security manager enabled.

The typo needs to be fixed by that is not the problem (at least it didn't fix the problem for me).

I have created a lib and copied the jar in it then it works.
I still have:
ava.security.AccessControlException: access denied (java.lang.RuntimePermission accessClassInPackage.org.apache.coyote.http11)
but the jsp is compiled correctly and subsequent requests are working with problems.

in fact the problem are the symlink to ../file in lib

Even I have a copy of the ../file in lib I still have:
java.lang.RuntimePermission accessClassInPackage.org.apache.coyote.http11

Note that I also get the same problem with a vanilla tomcat (6.0.37) on RHEL6.

Created attachment 753604 [details]
Patch to fix the problem

That is the r2203 of jbossweb.

See https://issues.apache.org/bugzilla/show_bug.cgi?id=55019

Created attachment 757740 [details]
tomcat6 and tomcat7 catalina.out

Following the repdoducer in comment#0 still produces various errors in catalina.out for both tomcat6 and tomcat7 (please see attached logs).

Executing $ curl http://localhost:8080/smtest/test.jsp produces no output at all, and exits with code 0. No additional message is produced in catalina.out.

SEVERE: Error deploying web application directory smtest
java.lang.NoClassDefFoundError: org/apache/catalina/loader/ResourceEntry
	at org.apache.catalina.loader.WebappClassLoader.findLoadedClass0(WebappClassLoader.java:3212)
	at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1573)
	at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1526)
	at org.apache.catalina.core.StandardWrapper$1.run(StandardWrapper.java:1111)
	at java.security.AccessController.doPrivileged(AccessController.java:280)
	at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1107)

after applying Jean-Frederic's patch i'm not able to reproduce the NCDFError. But, testing tomcat7 i do get a security exception. Note: the error occurs only with the rpm distro as was reported above.

the error occurs whether or not smtest is deployed (it deploys without error).


- install tomcat7 rpms
- change SECURITY_MANAGER="true" and fix the typo in /usr/sbin/tomcat7 (this is fixed in my workspace)
- service tomcat7 start
- curl http://localhost:8080
- an error page is returned citing the security exception

snip:
The server encountered an internal error that prevented it from fulfilling this request. exception java.security.AccessControlException: access denied (java.lang.RuntimePermission accessClassInPackage.org.apache.jasper)
	java.security.AccessControlContext.checkPermission(AccessControlContext.java:393)
	java.security.AccessController.checkPermission(AccessController.java:558)
	java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
	java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1529)

catalina.policy contains the correct permissions that work using the zip distro.


There are two differences between the rpm distro and the zip distro:
1. the rpm distro installs systemd init files. the first runs as root and then starts tomcat as TOMCAT_USER. In the zip (and downstream distro) this isn't true

2. Many of the jars in /usr/share/tomcat7/lib are symlinks. in the case of jasper.jar, the symlink target is in the lib directory.

i can try to eliminate the symlinks and see what happens.

The above doc isn't true: 
 starting with the following: <screen>java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "accessClassInPackage.org.apache.jasper")</screen> The symbolic link is now fixed and the security manager works as expected with JBoss Enterprise Web Server 2.0.1.

I'm still working as i believe accessClassInPackage for org.apache.jasper is just the tip of the iceberg.

In the text is wrong the problem is
"<jsp:include page="blabla" flush="true"/> failed to compile under security manager"
It fails with "java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "accessClassInPackage.org.apache.jasper"
It was due to 2 problems: the symlink in rpm won't work under security manager and a Constant subclass was inaccessible.

The symlinks have been changed in real files and the Constants has been instanced in a calling class.

NOTE:
The smtest is just "an example" of a jsp that includes another one and trigger the error.

From David's comment (comment #16) it sounds like this bug is not a resolved issue but rather remaining a known issue for 2.0.1. Can someone confirm? 

Also, updating doc text according to comment #16 and comment #17 shortly.

The symbolic link in the JBoss Enterprise Web Server RPM does not work correctly
I would use plural:
Some symbolic links of the JBoss Enterprise Web Server RPM do not work under java security manager

For details those links are going one level down ( ../ ) and java under the security manager doesn't seem to allow that.

Do we need the example? Can a customer get the smtest webapp somewhere? If yes the example is needed otherwise we should remove it.

Updated the doc text. Jean-Frederic, please confirm whether it is now correct.

"The symbolic link in the JBoss Enterprise Web Server RPM does not work correctly..."
Better:
Some symbolic links of the JBoss Enterprise Web Server RPM do not work under java security manager

Jean-Frederic, are you looking at the diff in comment #20? From what I can see in the doc text field, it is already changed to "Some symbolic links..." but please have a look and let me know if there is still something you think should be different.

the Doc Text field is OK.

Created attachment 765599 [details]
tomcat6 catalina.out

Created attachment 765600 [details]
tomcat7 catalina.out

Various errors:
java.lang.NoClassDefFoundError
org.apache.catalina.LifecycleException
java.lang.IllegalStateException

on:
tomcat6-6.0.37-8_patch_01.ep6.el5
tomcat6-6.0.37-10_patch_01.ep6.el6
tomcat7-7.0.40-8_patch_01.ep6.el5
tomcat7-7.0.40-5_patch_01.ep6.el6

Produced by:
1. echo SECURITY_MANAGER=true >> /etc/tomcatX/tomcatX.conf
2. service tomcatX start

See attachments tomcat6 and tomcat7 catalina.out

Those look example applications why are you testing them?

if we ship the examples we should document a bit to get they working because their part is commented out in the policy file.

i've retested tomcat6-6.0.37-10_patch_01.ep6.el6 and can't reproduce this. 

You don't need to inject SECURITY_MANAGER into tomcat6.conf -- it's considered better practice to set the value in /etc/sysconf/tomcat6. The reasoning behind it is cohabitating instances can run with different configurations. The entry is there, you just need to remove the comment and change the value s/false/true

As per the examples, we don't ship them in the whole due to CVE-2007-1355. It's been the same for years. curl http://localhost:8080/examples/jsp/ will produce a page with some details.

Testing, i used an unmodified policy file. I modified the init script for tty confirmation that tomcat was starting as expected.

- edited  /etc/sysconfig/tomcat6 SECURITY_MANAGER="true"
- edited /etc/tomcat6/tomcat-users.xml to allow access for user tomcat; (wanted to see if the manager apps were affected)
- service tomcat6 start
- curl http://localhost:8080/ returns the welcome page
- - saw no error/exception/severe messages in logs
- curl -u tomcat:tomcat http://localhost:8080/examples/
-- found no error/exception/severe messages in the logs
- curl http://localhost:8080/examples returned the expected page
- curl http://localhost:8080/examples/jsp returned the expected page

I know this is frustrating, but i can't reproduce.

My deepest apologies. I think I know what happened.
I think last time I tried to verify this bug I accidentally tested it on IBMJDK. That was due to the fact that if you install all available JDKs from rpm (OpenJDK, OracleJDK, IBMJDK both 1.6 and 1.7) the 'alternatives' mechanism will automatically pick IBMJDK1.7. That means I was unknowingly running into bz#901081.

I've retested this bug again on OpenJDK1.7 with reproducers from comment#30 and comment#0 and wasn't able reproduce ANY of the errors above. Yay!

VERIFIED on:
tomcat6-6.0.37-8_patch_01.ep6.el5
tomcat7-7.0.40-9_patch_01.ep6.el5
tomcat6-6.0.37-10_patch_01.ep6.el6
tomcat7-7.0.40-5_patch_01.ep6.el6