Description of problem: tomcat doesn't respect some custom policies for webapps declared by 'codeBase'. Version-Release number of selected component (if applicable): 8.0.32 How reproducible: always, security manager enabled. grant with no codeBase specified works fine. Steps to Reproduce: 1. deploy the example war file attached (catalina_policy_test.war); 2. browse 'http://localhost:8080/catalina_policy_test/index.html' (change the port if needed); 3. an AccessControlException is raised. Actual results: An AccessControlException is raised for "java.util.PropertyPermission" "user.home" action "read". Expected results: The user.home property should be printed. Additional info: vanilla package from tomcat.apache.org (8.0.35) doesn't have this problem.
Created attachment 1164128 [details] example .war file test case
Created attachment 1164129 [details] current catalina.policy
Created attachment 1164131 [details] current tomcat.conf
Created attachment 1164133 [details] source code of the test case
Created attachment 1164135 [details] stacktrace
Just to ease the reading of catalina.policy, follows bellow the role a wrote to the test case: grant codeBase "file:${catalina.base}/webapps/catalina_policy_test/-" { permission java.util.PropertyPermission "user.home", "read"; }; I replaced ${catalina.base} for ${catalina.home} with no success.
Created attachment 1164136 [details] current catalina.policy v2 fix ${catalina.home} spelling.
It looks like this might be an issue in tomcat (because it works with 8.0.35; did you test with 8.0.32 upstream?), not specific to the Fedora package, so it should be raised in the upstream project. However I recently pushed an update into updates-testing that rebased tomcat to 8.0.36. Can you test with that to verify whether or not the problem still exists? The update is here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-2b0c16fd82 If it's fixed, then I'll add this bug to the update so that it gets closed when the build is pushed to stable.
Actually that was the wrong update link. The fc23 one is https://bodhi.fedoraproject.org/updates/FEDORA-2016-0a4dccdd23
(In reply to Coty Sutherland from comment #9) > Actually that was the wrong update link. The fc23 one is > https://bodhi.fedoraproject.org/updates/FEDORA-2016-0a4dccdd23 I updated the package and tested but the issue is still reproducible. So, the recommendation is to me let upstream know about this issue, right?
(In reply to Coty Sutherland from comment #8) > It looks like this might be an issue in tomcat (because it works with > 8.0.35; did you test with 8.0.32 upstream?), not specific to the Fedora > package, so it should be raised in the upstream project. However I recently > pushed an update into updates-testing that rebased tomcat to 8.0.36. Can you > test with that to verify whether or not the problem still exists? The update > is here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-2b0c16fd82 > > If it's fixed, then I'll add this bug to the update so that it gets closed > when the build is pushed to stable. sorry, i missed something: did the test case work for you? hm. so, it's my problem. there is some configuration between the vanilla tomcat and fedora's i'm not aware of. thank you very much for your effort.
> I updated the package and tested but the issue is still reproducible. Thanks for testing. > So, the recommendation is to me let upstream know about this issue, right? Yes, but this looks like expected behavior to me. All applications should not have access to the specified environment variable, so if your application needs it, then you need to adjust the policy accordingly. > sorry, i missed something: did the test case work for you? No, I tested with ASF tomcat 8.0.32 and 8.0.35 and both show the same behavior when using the security manager. The problem is that the default policy does not allow this behavior and therefore it's expected. If you don't agree with that assessment please open an upstream bug with ASF tomcat and suggest a change in the policy to be less strict.