You are viewing a plain text version of this content. The canonical link for it is here.
Posted to xindice-users@xml.apache.org by Geoffrey Shuetrim <ge...@galexy.net> on 2005/06/17 04:09:29 UTC
Tomcat security manager settings for Xindice database located
outside the webapp directory
I am struggling with the security manager settings for Tomcat 4 running
on Sun Java 1.42 (on Debian testing) for Xindice databases that are
stored outside of the xindice webapp itself.
I have set the dbroot attribute in the xindice system.xml
to /var/xindice/db/
The db directory is owned by root but is read and write accessible to
all (thoughts on which user should own it and what access rights make
sense would be much appreciated too).
If I start tomcat4 with the security manager turned off, all goes well
and the xindice webapp runs fine.
If I start tomcat4 with the security manager running but with the
security policy configured with the following xindice specific
permission
grant codeBase "file:{catalina.home}/webapps/xindice/WEB-INF/-" {
permission java.io.FilePermission "/var/xindice/db/*",
"read,write,delete";
};
then I expect the xindice application to be able to read, write and
delete content in the /var/xindice/db.
Sadly, I get the following stack trace as the root cause of a problem:
java.security.AccessControlException: access denied
(java.io.FilePermission /var/xindice/db read)
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:269)
at java.security.AccessController.checkPermission(AccessController.java:401)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:524)
at java.lang.SecurityManager.checkRead(SecurityManager.java:863)
at java.io.File.exists(File.java:678)
at org.apache.xindice.core.Collection.setCollectionRoot(Collection.java:1324)
at org.apache.xindice.core.Database.setConfig(Database.java:260)
at org.apache.xindice.core.Database.getDatabase(Database.java:89)
at org.apache.xindice.server.XindiceServlet.init(XindiceServlet.java:166)
at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:888)
at org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:621)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:163)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:596)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:433)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:948)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:144)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:596)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:433)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:948)
at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2358)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:133)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:596)
at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:118)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:594)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:116)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:594)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:433)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:948)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:127)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:596)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:433)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:948)
at org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:152)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:799)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:705)
at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:577)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:683)
at java.lang.Thread.run(Thread.java:534)
Any thoughts on how to sort this out without turning off the security
manager?
Regards
Geoff Shuetrim
Re: Tomcat security manager settings for Xindice database located
outside the webapp directory
Posted by Geoffrey Shuetrim <ge...@galexy.net>.
Vadim
Thanks for the quick reply and nice spotting of the typo. Unfortunately
the typo was in the email I sent but not in the policy file that I used.
I tried a variety of hyphens and asterisks to handle the classes being
given the permissions and the directory that the permissions relate to
(my understanding is that * implies the specified directory and its
children whereas the - implies the specified directory and its contents
- including all descendant directories).
Still no luck with any of those variants but it is good to know that I
am looking in approximately the right place.
Cheers
Geoff Shuetrim
On Fri, 2005-06-17 at 08:57 -0400, Vadim Gritsenko wrote:
> Geoffrey Shuetrim wrote:
> > I am struggling with the security manager settings for Tomcat 4 running
> > on Sun Java 1.42 (on Debian testing) for Xindice databases that are
> > stored outside of the xindice webapp itself.
> >
> > I have set the dbroot attribute in the xindice system.xml
> > to /var/xindice/db/
> >
> > The db directory is owned by root but is read and write accessible to
> > all (thoughts on which user should own it and what access rights make
> > sense would be much appreciated too).
> >
> > If I start tomcat4 with the security manager turned off, all goes well
> > and the xindice webapp runs fine.
> >
> > If I start tomcat4 with the security manager running but with the
> > security policy configured with the following xindice specific
> > permission
> >
> > grant codeBase "file:{catalina.home}/webapps/xindice/WEB-INF/-" {
> > permission java.io.FilePermission "/var/xindice/db/*",
> > "read,write,delete";
> > };
>
> Probably exception happens because of typo - '$' is missing above. I'm not sure
> that '-' syntax allows for sub-directories, so I'd try adding 'classes' to the
> path. So result will be:
>
> grant codeBase "file:${catalina.home}/webapps/xindice/WEB-INF/classes/-" {
> permission java.io.FilePermission "/var/xindice/db/*", "read,write,delete";
> };
>
> Vadim
>
>
> > then I expect the xindice application to be able to read, write and
> > delete content in the /var/xindice/db.
> >
> > Sadly, I get the following stack trace as the root cause of a problem:
> >
> > java.security.AccessControlException: access denied
> > (java.io.FilePermission /var/xindice/db read)
> > at java.security.AccessControlContext.checkPermission(AccessControlContext.java:269)
> > at java.security.AccessController.checkPermission(AccessController.java:401)
> ...
> >
> > Any thoughts on how to sort this out without turning off the security
> > manager?
> >
> > Regards
> >
> > Geoff Shuetrim
>
Re: Tomcat security manager settings for Xindice database located
outside the webapp directory
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Geoffrey Shuetrim wrote:
> I am struggling with the security manager settings for Tomcat 4 running
> on Sun Java 1.42 (on Debian testing) for Xindice databases that are
> stored outside of the xindice webapp itself.
>
> I have set the dbroot attribute in the xindice system.xml
> to /var/xindice/db/
>
> The db directory is owned by root but is read and write accessible to
> all (thoughts on which user should own it and what access rights make
> sense would be much appreciated too).
>
> If I start tomcat4 with the security manager turned off, all goes well
> and the xindice webapp runs fine.
>
> If I start tomcat4 with the security manager running but with the
> security policy configured with the following xindice specific
> permission
>
> grant codeBase "file:{catalina.home}/webapps/xindice/WEB-INF/-" {
> permission java.io.FilePermission "/var/xindice/db/*",
> "read,write,delete";
> };
Probably exception happens because of typo - '$' is missing above. I'm not sure
that '-' syntax allows for sub-directories, so I'd try adding 'classes' to the
path. So result will be:
grant codeBase "file:${catalina.home}/webapps/xindice/WEB-INF/classes/-" {
permission java.io.FilePermission "/var/xindice/db/*", "read,write,delete";
};
Vadim
> then I expect the xindice application to be able to read, write and
> delete content in the /var/xindice/db.
>
> Sadly, I get the following stack trace as the root cause of a problem:
>
> java.security.AccessControlException: access denied
> (java.io.FilePermission /var/xindice/db read)
> at java.security.AccessControlContext.checkPermission(AccessControlContext.java:269)
> at java.security.AccessController.checkPermission(AccessController.java:401)
...
>
> Any thoughts on how to sort this out without turning off the security
> manager?
>
> Regards
>
> Geoff Shuetrim