Posted by flozano
on July 31, 2007 at 6:40 AM PDT
Why can't we run popular Java applications on shared hosting plans? There are real techinical issues, or is it just a perception problem?
During the latest days I've been fighting with my hosting provider because I tried to deploy Xwiki (xwiki.org) in my hosted web site. The core issue was XWiki requires that the web container security policy includes:
permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
Actually, it's Struts and Velocity that requires that, not XWiki code itself. See for more info
This permission allows the use of reflection to access private and protected methods and attributes.
My ISP argues that they can't grant this without compromising the shared web container integrity, and uses Sun Java SE Javadocs as proof, see:
A quick google search convinced me that all major Java frameworks including but not limited to Struts, Hibernate and Spring needs this permission, so banning it from the security policy means the shared hosting plan is useless for the vast majority Java applications.
Worse yet, mailing list postings from many sources indicates many other follow the same policies as my own.
Is this good business? Are all customers interested in Java hosting using â€œsemi-dedicatedâ€ servers, or virtual machines? Can you imagine a PHP hosting plan that bans Pear, PHPlib, ADODB, PhpNuke, PhpMySQLAdmin and other popular PHP libraries and applications? Why the same reasoning doesn't applies to Java hosting?
Being pragmatic, all that Java frameworks, including many from Apache Software Foundation, couldn't be wrong. It doesn't make sense they would require something that poses a significant security treat.
I guess that using isolated class loaders for each web application context (as stated by the Servlet spec) should prevent any use of reflection to get sensitive information from other customers using the same shared web container, so there should no harm granting the permission required by Struts.
Besides I think granting suppressAccessChecks for ReflectPermission would not make a shared Java web container security worse than mod_php or mod_perl inside Apache or IIS. Am I wrong?
If I am wrong and the security implications of granting supressAccessChecks are realy severe, why don't pre-configure the most popular frameworks on the web container shared lib folder and granting permissions just to them, so that any Struts jar from the customer applications WEB-INF/lib folder are ignored? Would this be so hard for a hosting provider to do?
Anyway making it hard to deploy popular applications and frameworks on shared hosting providers hurts Java popularity and indirectly the profits of all who bet their carres and business on the Java platform. If there's a real problem, framework developers should fix their code so they can run inside a tightier security policy. If not, docs need to be updated to state the real risk and pactices to mitigate it. Letting eveyone be limited to use dedicated web containers may help selling java ee server licenses and suppport, but doesn't help the community in the long run.