Fernando Lozano's Blog

Shared web hosting versus Java frameworks

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

http://struts.apache.org/2.0.6/docs/sunone-70.html

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:

http://java.sun.com/j2se/1.5.0/docs/guide/security/permissions.html

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.

Comments

• Hello Fernando,
  I think we java folks are some kind of second class citizens in the hosting world, we pay more and get less...
  It seems like there is little market for serious hosted application development in Java, whereas there is much for Php. Hope this will be better one day :-(
  Regards,
  Riccardo

  Posted by: riccardocossu on July 31, 2007 at 07:56 AM

• Riccardo, you stated a fact: we are treated like second class citzens by hosting providers. But given the sheer number of Java developers and applications, there should be a strong demand. I guess it's more a case of "marketing blindness".

  I also found most of the time techinical people from hosting providers have poor skills, and will use whatever the "defaults" are, without questioning. Then the wording of Sun docs and many framework docs hurt us.

  Posted by: flozano on July 31, 2007 at 08:08 AM

• I think that most of Java web application (which normally have higher budgets than their LAMP equivalent) are systems worth running on dedicated hosts because they are worth the extra cost.
  And most of us Java folks work on such application so our number is not significative when we are talking about shared hosting.
  About the low skill of technical people from hosting providers you are completely right: here in Italy hundreds of sites from one of the major provider have recently been hacked because of a bug in their platform...

  Posted by: riccardocossu on July 31, 2007 at 08:32 AM

• 
  There are three reasons in my opinion.

  The first is that Web hosting is a low-margin business, so providers tend to provide free software (price being more important than liberty to them). Due to licensing restrictions, Java has only recently been available in the default install of the free operating systems they tend to use for hosting. Since Apache and PHP were always readily available with less effort, it is the most common solution.

  Secondly, I'd guess that Java Web apps tend to require more memory than the equivalent Apache/PHP solution. Therefore, they can serve fewer customers on the same hardware, thus lowering their profits somewhat.

  Finally, I suspect that Java Web apps tend to be most widely developed and deployed in a corporate environment which provides its own hosting infrastructure, or at least uses dedicated/co-located servers. Supply and demand comes into play here, because if people developing Java Web apps used shared Web hosting providers, then there would be a supply of Web hosting providers offering that feature to them.
  

  Posted by: tomwheeler on July 31, 2007 at 09:12 AM

• Hi Tom,

  About the low margin, most big providers have been offering Java JSP and Servlet support for a number of years, most using Tomcat and some using JBoss. For them, it's as free as PHP or Perl.

  About memory, one Java web app requires more memory than a single PHP application. But when you share the same LAMP or Tomcat installation with dozen users, the differente in memory will be negligible, as all customers will use the same JVM and web container.

  About demand, I wonder how much of it is reality and how much is perception and misconception. If you demand Java support from your ISP but you don't get it, you'll switch to PHP or ASPm whatever's available, because that's the path of least resistance. So I think there should be actions from Sun, other Java vendors and the community so more hosting providers provide real (i.e. not crippled) Java support.

  But what about the "techinical" reasons to offer a crippled Java environment, with a too restrictive Security Manager? Aren't there really no options beside a dedicated JVM for each customer?

  Posted by: flozano on July 31, 2007 at 09:50 AM

• 
  The assertion that most big providers offer JSP and servlet support is news to me. I'd love to know the names of a few of these because I might then change providers for some of my sites.

  As I said, Java and JSP support was not as readily available as Apache/PHP until just a few months ago. Sure, you could get it, but the sysadmin had to fetch the JDK and Tomcat and install it on the machine, whereas Apache and PHP were available as part of the OS installation. Now that Java is open source, the previous licensing and distribution restrictions are gone, so it will probably become more widely available from hosting providers in the future.

  Posted by: tomwheeler on July 31, 2007 at 01:28 PM

• Hi Tom,

  Maybe I'm biased because here (Brazil) it's true the big hosting providers support Java... but with too restricted security policies, which prevents using Struts and other popular frameworks.

  But dowloading and installing free Sun Java + free Apache Tomcat is not that difficult. This would not prevent a hosting provider from offering Java support. If they don't adopt more flexible security policies, it won't matter they switch to OpenJDK, we'll still be prevented from using shared hosting for real Java web aplications.

  Posted by: flozano on July 31, 2007 at 07:36 PM

• I can run anything on the java hosting at webappcabaret.

  I'm not saying they are perfect, but they basically let you do what you want with your JVM.

  Posted by: texas_mustang on August 01, 2007 at 05:32 AM

• I think those frameworks shouldn't depend on any security setting (or any other JVM configuration) that is not default. They could detect the required setting and use optimized code that depends on them conditionally; otherwise, fall back to alternative code that doesn't need it. For example, you can read an object's properties by either accessing its field (which requires special security settings for private ones) or calling its public getter method (which is slower, but will always work - if there are getters of course). A second alternative is code instrumentation: the framework can always install a classloader that injects code in your classes to provide special access, or for other reasons.

  Another solution is installing the framework's jars (core ones at least) in the container's lib directory. The container typically grants all permissions to classes installed in its root classpath, and restricts only classes loaded from deployed apps. Of course the problem there is versioning; a shared hosting server may have one app requiring Hibernate 3.2 and other that depends on Hibernate 3.0, not to mention Spring, Struts etc. This is where JavaEE wins and everything else loses - if the server is, say, a full JavaEE 5.0 container, it offers a boatload of powerful APIs that many apps can rely on. You may like Struts 2 better than JSF and Hibernate's proprietary API better than EJB 3.0 / JPA, but for the hosting provider, there is no question that the consolidated set of JavaEE APIs is immensely easier to support simply because it avoids the whole versioning issue.

  There is another, upcoming solution with module systems - either OSGi or Java SE 7's (JSR277) modules will allow a scenario where the hosting provider installs many versions of Spring in the root classpath, and each deployed app can depend on its preferred version. This is may also be a BIG win in the memory usage. JavaEE's memory footprint is not just a single-time boot footprint; it becomes worse if a server contains 10 deployed apps, each app includes 20Mb of dependent libraries, and each app's libs are loaded and JIT-compiled separately, even when they're the exact same version in all apps... so, your 20Mb of dependencies per app quickly becomes 200Mb of overhead for a loaded server with 10 apps active. It's a performance issue too, because the JIT's code cache area is shared, so less native code can be stored per individual app.

  Posted by: opinali on August 01, 2007 at 06:33 AM

• 
  PHP is popular for hosting providers because it's cheap to get, easy on resources, and easy on the overall system.

  The Apache/PHP combination has an advantage of being very stable and very difficult to corrupt. It's very hard for badly behaved PHP users to destabilize either the actual instance, or the server itself. As an administrator, you have all of the facilities of the host operating system at your disposal to help manage the various processes.

  While Apache/PHP is a shared environment, each instance of Apache serving a connection (under 1.3) is independent of any other instance, since they are separate processes. The system admin can then limit the impact of an individual process: memory, file handles, run time, cpu load, etc. Any process that gets out of hand can be summarily (and automatically) killed by the OS, and Apache will happily restart a new one.

  So, for example, there's no way that a badly behaved user could create a 2GB array and stuff it in to a long lived HTTPSession, thus smashing the Java heap for everyone else on the same instance.

  Next, of course, you have the virtual hosting capabilities. You can host a 1000 hosts under an Apache server. If you have a bunch of low traffic sites, then when a site does gets traffic, the system loads up the PHP file, sticks it in its OS level file cache, PHP evaluates it and spits the results back.

  If that site is never hit again, the only lingering impact on the server is the time the PHP source file lives in the OS file cache. In due time, that will be reclaimed as other files are used on the server. So, shortly after the PHP page is loaded and evaluated, save for perhaps a log entry, there's no evidence that the page was ever loaded. And any evidence remaining is stored on a disk somewhere, and attributable to the account holder.

  This makes bulk hosting cheap for hosters, because most sites are low traffic. Put cheap plans on a "oversold" host, and if and when a user complains about traffic, move them to a machine with more capacity, leaving the 999 other low traffic blogs and vanity pages on the same server.

  Contrast that to a Java solution, once a JSP is loaded, and compiled in to a servlet, that class is pretty much stuck in the JVM for the long haul, as the JVM doesn't really like GCing classes. Plus you have the general overhead in RAM of the Webapp itself.

  Simply put, idle applications in PHP consume disk space, whereas idle applications Java consume RAM.

  Also, if a server should become sorely tapped from some kind of surge, a PHP server can readily SWAP its way out of it, and when the surge passes, recover easily.
  A java server tends to go OutOfMemory, and not SWAP (God help the poor souls swapping Java...). The app servers have a tendency to not behave well in OOM conditions. Apps break, etc. And the damage can be long term (since "Thing t = new Thing()" isn't supposed to "fail"). I personally consider a server that's hit OOM to be damaged. The software is simply not happy, and may require a restart.

  And even if the server doesn't, because it has man years of engineering put in to work around that potential problem in sensitive areas, the users application may well not. So, when User A puts the server in to an OOM state, it may well corrupt innocent User B who will need a restart/redeploy to clean up their instance.

  A similar event would most likely only happen to a PHP user if the host managed to let the disk drives fill up, which is getting less and less likely today.

  Mind, I'm not a PHP fan, but I think that the solution is particularly well suited to the value web hosting market much moreso than Java because of this robust nature.

  If you seriously want to run Java, I suggest the VM route. I think you'll be much happier, but it will cost you more.

  Posted by: whartung on August 01, 2007 at 03:47 PM

• Lets not kid ourselves here. Java plays terribly with others. This is not a fault of your hosting provider in any way shape or form. There was very little design though in either the JVM or the web application frameworks for shared hosting. Java is a memory hog. Not just for the small scale/big scale argument - but for any scale.

  Now, where your running a mission critical financial business off your app (like we do at work) - storing data as 2 byte unicode instead of UTF-8 doesn't much matter. But, for a hosting provider like Dreamhost, needing 64 mb a process (as a start) is impossible.

  Additionally, there is false logic that because the major frameworks require a permission, it must be safe. That assumption is based on the thought that the frameworks were designed for a shared hosting scenario. Having reflection permissions will indeed allow you to come up with creative ways to either bring down the VM instance, peek into other peoples data, or take up more than your share of resources.

  Sun was supposedly experimenting with a multi-tenant VM some years back. If they combined that with the memory utilization work going on for the Consumer JVM and the new license, it's possible that shared hosting Java could be viable. But, with the multitude of perfectly good alternatives (Ruby, Python, PHP, Perl, etc) - I don't see a tipping point in the future.

  -Adam Malter

  Posted by: amalter on August 01, 2007 at 04:07 PM

• Hi people, thans for the feedback.

  I still cannot figure out why the reflection permissions would be so bad for security, and the reliability of the PHP/Apache multiprocess model is changing because Apache 2.x offers multithreaded execution, so a PHP or Perl application is now also able use "creative" ways to tap into other sessions data and harm the overall web server stability.

  But memory use, specially the impossibility of GCing classes themselves, poses a very real problem. I wonder if old ASP and the newer ASP.NET, which are pretty popular among hosting providers, behave more like Java or more like PHP in this respect.

  Posted by: flozano on August 01, 2007 at 05:58 PM

• 
  Reflection permission may be bad because it lets an intruder essentially crawl the space of the JVM, looking for classes.

  It's already trivial to create a heap dump tool in pure Java that will crawl the heap. Once you can crawl the heap, you can start looking for "interesting" objects (say, perhaps, data connection pool objects that most likely have DB passwords stored in them). JVM heaps are not "multi-user". You can sort of play that game with the Security system, and have different security levels via different class loaders, but as you've discovered, the rights tend to be a bit coarse.

  In this example, it would be fine to give you reflection over your applications classes, but not over other classes within the server (system classes, classes of other applications).

  But either the rights don't quite work that way (I haven't look at this in detail), or the server vendors haven't done the due diligence yet to make this a reality for the current crop of servers.

  Both scenarios are likely, but most especially scenario 2. Simply put, the modern servers aren't designed for the multi-user hosting scenario. They can be used in that mode, but making them really friendly to that deployment pattern of several different and potentially hostile users just hasn't been a priority for the designers.

  As for Apache 2.0, multi-threading is a deployment option, but not required. It can still run using the forked model. Linux specifically happens to do forking VERY well. So, while hosting companies have the option of using Apache 2.0 in threaded mode, doesn't mean that they will for this deployment scenario, and for the reasons that I stated earlier.

  As with everything else, with modern Virtualization technologies, and the abundance of memory, cheap Java hosting is becoming more viable without having to address these issues directly. The primary problem that distinguishes the Virtual Server scenario from the classic Virtual Host scenario (beyond the resources necessary), is simply IP addresses. Virtual Servers require unique IPs, whereas Virtual Hosts do not. Virtual Hosting is the primary reason we haven't completely consumed the IPv4 addess space. It took a LOT of pressure off of it by being able to share IPs across several different hosts.
  With IPv6 apparently finally coming down the road, this too will be a non-issue and we'll have more than enough IP's to go around.

  Posted by: whartung on August 02, 2007 at 11:00 AM

• Reliable Java Shared Hosting is unatenable, unless one uses the 1:M smodel (1 apache server -> many servlet engines, one per app - memory hog.) .

  One of the problem lies with the fact that hot redeploy doesn't work. Just look at all webapp classloader memory leaks (due to the classloader not being garbage collected as a reference is being held in the parent) which usually leads to PermGen OOM's.

  Just look at some of the offerenders in the link listed below -

  http://opensource.atlassian.com/confluence/spring/pages/viewpage.action?pageId=2669

  Those libraries are used in most java web frameworks.
  

  Posted by: gdaswani on August 03, 2007 at 08:56 AM

• I've had a very good experience with Ubiquity's Linux web hosting plans as well, including several Struts apps. From my experience, the level of permissions and options varies pretty wildly between the different hosting options out there. It may not be ideal if you're not running a full server of your own, but I wouldn't call something reliable unattainable either.

  Posted by: qwidjib0 on September 18, 2007 at 10:41 PM

• I running my services of hosting java wich: java support,jsp,servlets,wars,j2ee,j2se,jvm, sql server or mysql and others supports in dadycomp.Are going very fast wich servers the last generation clovertown quad core chipsets proccesors.Is the best option for companies,developers and java web applications.

  Posted by: megatrols on January 01, 2008 at 10:29 AM

• Shared Java hosting is untenable for the reasons noted. Private Java hosting (one http server fronting many JVM) works fine for all but the most memory hungry sites.

  The prices are somewhat higher because memory has to be allocated which doesn't allow 300 sites to be put on one server. Still, there are a bunch of hosts at or below $20 a month - one called (somewhat less than creatively) Java Web Hosting is about $13.

  Posted by: geolook on June 13, 2008 at 05:20 PM

This work is licensed under a Creative Commons License.