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]
