DO NOT REPLY [Bug 6660] - Catalina with SecurityManager is possibly broken.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6660. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6660 Catalina with SecurityManager is possibly broken. [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2002-02-25 18:36 --- The implementation of the Java SecurityManager is significantly different between Tomcat 3.2/3.3 and Tomcat 4. The Tomcat 4 version implements much finer control over granting permissions in the policy file. Even down to granting permisions to individual classes within a jar. jar's in /WEB-INF/lib have a completely different codeBase than classes in /WEB-INF/classes. To fix your problem add the following grant to your catalina.policy grant codeBase jar:file:{path-to-webapp}/WEB-INF/lib/WriteFile.jar!/- { permission java.io.FilePermission /home/client/-, read,write,delete; permission java.util.PropertyPermission *, read; }; -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 6660] - Catalina with SecurityManager is possibly broken.
What if I want my users to put any *.jar files on /lib ( which will be controled by the policy anyway... ) ? Do I need to configure each of them on catalina.policy and then restart Tomcat ? ( this is not good... :(( ). [EMAIL PROTECTED] wrote: DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6660 Catalina with SecurityManager is possibly broken. [EMAIL PROTECTED] changed: What |Removed |Added Status|NEW |RESOLVED Resolution| |WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2002-02-25 18:36 --- The implementation of the Java SecurityManager is significantly different between Tomcat 3.2/3.3 and Tomcat 4. The Tomcat 4 version implements much finer control over granting permissions in the policy file. Even down to granting permisions to individual classes within a jar. jar's in /WEB-INF/lib have a completely different codeBase than classes in /WEB-INF/classes. To fix your problem add the following grant to your catalina.policy grant codeBase jar:file:{path-to-webapp}/WEB-INF/lib/WriteFile.jar!/- { permission java.io.FilePermission /home/client/-, read,write,delete; permission java.util.PropertyPermission *, read; }; -- To unsubscribe, e-mail: For additional commands, e-mail: - Do You Yahoo!? Yahoo! Sports - Coverage of the 2002 Olympic Games
Re: DO NOT REPLY [Bug 6660] - Catalina with SecurityManager is possibly broken.
What if I want my users to put any *.jar files on /lib ( which will be controled by the policy anyway... ) ? Do I need to configure each of them on catalina.policy and then restart Tomcat ? ( this is not good... :(( ). grant codeBase jar:file:{path-to-webapp}/WEB-INF/lib/WriteFile.jar!/- { Doing: 'grant codeBase jar:file:{path-to-webapp}/WEB-INF/lib/-' should get the job done. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 6660] - Catalina with SecurityManager is possibly broken.
Hi Remy, Doing: grant codeBase jar:file:{path-to-webapp}/WEB-INF/lib/WriteFile.jar!/- { worked fine Doing: grant codeBase jar:file:{path-to-webapp}/WEB-INF/lib/- { did not worked. (even tried: grant codeBase jar:file:{path-to-webapp}/WEB-INF/lib/-!/- { did not worked. ) I'm reopening the bug report because if we can't grant permissions on all jars files on the /lib it will a maintanance hell for wenhosting... Thanks for the patience ! Renato. Remy Maucherat [EMAIL PROTECTED] wrote: What if I want my users to put any *.jar files on /lib ( which will be controled by the policy anyway... ) ? Do I need to configure each of them on catalina.policy and then restart Tomcat ? ( this is not good... :(( ). grant codeBase jar:file:{path-to-webapp}/WEB-INF/lib/WriteFile.jar!/- { Doing: 'grant codeBase jar:file:{path-to-webapp}/WEB-INF/lib/-' should get the job done. Remy -- To unsubscribe, e-mail: For additional commands, e-mail: - Do You Yahoo!? Yahoo! Sports - Coverage of the 2002 Olympic Games
DO NOT REPLY [Bug 6660] - Catalina with SecurityManager is possibly broken.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6660. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6660 Catalina with SecurityManager is possibly broken. [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2002-02-25 20:19 --- Sorry, my mistake, the URL specified for the codebase probably has to be a valid URL. I'm afraid this can't be fixed, then. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 6660] - Catalina with SecurityManager is possibly broken.
If you can point me out where in Catalina code I could take a look, I'll appreciate. Also if you need a beta-tester for your application, you count on me. Thanks ! Glenn Nielsen [EMAIL PROTECTED] wrote: I also administer Tomcat for web hosting purposes and am aware of the problems configuring per web application policies. I have been working on a redesign of the SecurityManager implementation in Tomcat 4 which will make administration of these policies easier yet still allow very strict policy settings. I don't know when this will be ready. Glenn [EMAIL PROTECTED] wrote: DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6660 Catalina with SecurityManager is possibly broken. [EMAIL PROTECTED] changed: What |Removed |Added Status|REOPENED |RESOLVED Resolution| |WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2002-02-25 20:19 --- Sorry, my mistake, the URL specified for the codebase probably has to be a valid URL. I'm afraid this can't be fixed, then. -- To unsubscribe, e-mail: For additional commands, e-mail: -- -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder | MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- -- To unsubscribe, e-mail: For additional commands, e-mail: - Do You Yahoo!? Yahoo! Sports - Coverage of the 2002 Olympic Games
Re: DO NOT REPLY [Bug 6660] - Catalina with SecurityManager is possibly broken.
If you can point me out where in Catalina code I could take a look, I'll appreciate. Also if you need a beta-tester for your application, you count on me. No need to submit a patch; it is quite easy to set simpler URLs for the CodeSource location, but apprently Glenn likes the possibility to set per-class permissions (a feature I introduced by accident when coding the WCL). Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 6660] - Catalina with SecurityManager is possibly broken.
Remy Maucherat wrote: If you can point me out where in Catalina code I could take a look, I'll appreciate. Also if you need a beta-tester for your application, you count on me. No need to submit a patch; it is quite easy to set simpler URLs for the CodeSource location, but apprently Glenn likes the possibility to set per-class permissions (a feature I introduced by accident when coding the WCL). I was just commenting on how it currently works. I really don't see a need to fine tune security down to the individual class in a jar. Ok. If the WebappClassLoader were changed so that policies granted as follows worked I would be happy. Of course the code base for the web application context and jar files would still be different due to how the WebappClassLoader works. No, why ? I can create whatever I want for the SourceCode location. I would have to add a new field to the ResourceEntry class, though (which doesn't seem to be a big problem). I was already considering changing it (as I wanted to be 100% compatible with the URLClassLoader), but I didn't see any bug reason to do so. grant codeBase=jar:file:{path-to-webapp}/WEB-INF/lib/some.jar { // Some permissions for this jar }; grant codeBase=jar:file:{path-to-webapp}/WEB-INF/lib/- { // Some permissions for this jar }; No, after the fix, it would be the same as for the URLClassLoader: grant codeBase=file:{path-to-webapp}/WEB-INF/lib/some.jar { // Some permissions for this jar }; grant codeBase=file:{path-to-webapp}/WEB-INF/lib/- { // Some permissions for the jars }; Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 6660] - Catalina with SecurityManager is possibly broken.
Remy Maucherat wrote: grant codeBase=jar:file:{path-to-webapp}/WEB-INF/lib/some.jar { // Some permissions for this jar }; grant codeBase=jar:file:{path-to-webapp}/WEB-INF/lib/- { // Some permissions for this jar }; No, after the fix, it would be the same as for the URLClassLoader: grant codeBase=file:{path-to-webapp}/WEB-INF/lib/some.jar { // Some permissions for this jar }; grant codeBase=file:{path-to-webapp}/WEB-INF/lib/- { // Some permissions for the jars }; I would prefer it if the difference in codeBase were left in WebappClassLoader. I'm quite sure the StandardClassLoader which was used before was generating the second type of source location URLs (file:{path-to-webapp}/WEB-INF/lib/some.jar). Here is the reason. The root context is the codeBase for JSP pages. The JSP pages require all permissions that any unerlying jar's need. Yet you may not want to grant all of the jar files all the permissions a JSP page has. If the web app root and the jars have the same codeBase there is no way to fine tune your security policies. By The root context is the codeBase for JSP pages, do you mean that the source code URL is file:{path-to-webapp}/ ? Of course this will be moot when my SecurityManager proposal is implemented. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]