Return-Path: Mailing-List: contact tomcat-user-help@jakarta.apache.org; run by ezmlm Delivered-To: mailing list tomcat-user@jakarta.apache.org Received: (qmail 10865 invoked from network); 5 Oct 2000 01:25:49 -0000 Received: from mercury.sun.com (192.9.25.1) by locus.apache.org with SMTP; 5 Oct 2000 01:25:49 -0000 Received: from taller.eng.sun.com ([129.144.250.34]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA03538 for ; Wed, 4 Oct 2000 18:25:50 -0700 (PDT) Received: from eng.sun.com (florence [129.144.251.146]) by taller.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id SAA10085 for ; Wed, 4 Oct 2000 18:25:46 -0700 (PDT) Message-ID: <39DBD8D7.1BF1B001@eng.sun.com> Date: Wed, 04 Oct 2000 18:26:47 -0700 From: "Craig R. McClanahan" X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: tomcat-user@jakarta.apache.org Subject: Re: Running Tomcat for an ISP References: <415081ABE0F8D31199BD00508BC2296651BA69@EXC01> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N "Taglang, Guillaume" wrote: > Hi, > > 2 questions about using Tomcat for an ISP: > - can I prevent users to make a System.exit() Under Java2 (JDK1.2 or later), Tomcat 3.2 lets you run webapps under a SecurityManager, so that you can fine tune the permissions that each webapp can have. Besides restricting System.exit(), you can impose any other restrictions (like access to only certain network ports on certain hosts, or access to only certain directories) supported by the protection model of Java. One thing to remember, though, is that a JVM operates under a single operating system username. Therefore, if you are running multiple webapps in the same JVM (for different customers), the files are all accessible (at the OS level) to non-Java programs running under that login. See more below. > > - can I prevent crashing when the user use a buggy native library (core > dump)? > How about not allowing native libraries? What ISP operators might want to think about is a two-tiered pricing model -- a higher price to have your own JVM, running under your own OS username, in which you can run your own webapps but nobody elses (so if you crash it you only hurt yourself), and an economy price for a shared JVM environment. This avoids the issue about OS user identity being shared as well. On the other hand, with hardware being relatively cheap, it's probably simpler to stick with just the JVM-per-customer approach and put up a farm of servers of appropriate size so that you don't care about the higher memory occupancy. > > Regards, > > Guillaume Craig McClanahan ==================== See you at ApacheCon Europe ! Session VS01 (23-Oct 13h00-17h00): Sun Technical Briefing Session T06 (24-Oct 14h00-15h00): Migrating Apache JServ Applications to Tomcat