Hi Sergiu, Just clarifing my previous message:
I also don't understand why is the access restricted to WEB/INF... The configuration is usually there, right? Anyway, I think the latest version of the code does not need this, but I'm not sure. By the way, what version of XWiki are you using?
I'm using 1.0. The access restriction for /WEB-INF solve a bug in the way XWiki looks for its own configuration files. The way it looks for, you get a SecurityException whenever the Web Container is running inside a SecurityManagerm such as when Tomcat is started with the "-security" flag. See my other post, where I provide a JSP page with a snipset of XWiki code and show you how it could be changed to work correctly with a security manager.
The access permissions for /WEB-INF don't "solve" the bug, but workround it. The code I provided in the other message is a real solution for the bug. Note that "/WEB-INF" is an absolute filesystem path that shouldn't exist in any real system. The problem is, the Java Security Manager throws a Security Exception *before* trying to access or cheching permissions on the real file system, so XWiki never gets a change to find out the path doesn't exist and it should try a web context relative path. My code snipet tries the web context relative path before trying an absolute filesystem path, so it won't get a SecurityException. []s, Fernando Lozano
Regarding log4j.appender.file.File, this is what should be done anyway, as I don't like having the log file right in the application directory. It should be in a directory for logs, either the one in tomcat, or the one for all system logs (on linux it's /var/log/). I always change the location to /tmp/xwiki.log. I don't know how can log4j be configured to use one of these directories regardless of the platform, since c:\ and tomcat-5.5.23 are very unstable properties to place in there.
I tried to use system properties to point to the log file location, but this didn't work. So far I'm stuck with a system-dependent absolute pathname. :-(
Regarding the reflection permissions, I think actually Velocity is responsible for this. I found http://issues.apache.org/jira/browse/VELTOOLS-66 stating that it cannot access classes defined in the container, only those included in JARs. We should find all the classes that are used directly and make a wrapper for them, as the wrapper would work fine, even if it does not do anything other than forwarding the call.
See:
http://struts.apache.org/2.0.6/docs/sunone-70.html http://forums.theplanet.com/lofiversion/index.php/charts/t35104.html http://garethevans.blogspot.com/2005/06/fun-with-tomcat-and-its-default.html
Those state that Struts itself needs reflection permissions. And it looks like other popular frameworks like Hibernate and Spring also need it.
Now my ISP state it cannot provide such a permission, because Java SE docs (See jdk-1_5_0-doc/docs/guide/security/permissions.html) states that:
"|suppressAccessChecks: |/Extreme caution should be taken before granting this permission to code/ ... This is dangerous in that information (possibly confidential) and methods normally unavailable would be accessible to malicious code."
To be honest, I don't think this would be a problem as most popular framework rely on it. As far as I know Java and other web environments, every installation of mod_php and mod_perl under Apache or IIS would be subject to the same risks. But I need arguments to convince my ISP, any help would be apreciated.
My ISP also uses http://jira.xwiki.org/jira/browse/XWIKI-348 and http://www.xwiki.org/xwiki/bin/view/AdminGuide/InstallationTomcat as "proof" that XWiki can't run on shared hosting. :-( Maybe some XWiki developer can fix those docs so they don't state anymore that shared hosting is impossible, but instead that it just requires proper configuration, like any application would need when the Security Manager is on.
[]s, Fernando Lozano