On Wed, Jul 22, 2009 at 12:36 AM, robert hickman < [email protected]> wrote:
> > ---- Trying to use CGI sounds like a bad idea. It's always full of > ---- security issues > > I have read trough the page that you linked to and the issues listed > ain't any different from the issues associated with developing PHP > applications. That's true. You could run your Java web server as "root" and enjoy the same lack of security you can get with all the PHP, Perl, and other "1st gen" solutions that seem to be the target of every script-kiddies repertoire (just watch your web logs, see what's being targetted...). And since java can now bind port 80, you can get rid of apache too. :-) Ah, the simple life! Ultimately, security (and the fact that someone thought about security ahead of time) is one of the big differences between hosting with java versus other "easier" alternatives. But it's also why you hear of those sites getting "owned" more regularly than others. (The java-based sites just go belly-up garbage collecting strings on each slashdotting :-) ) What exactly is the big win in reinventing the wheel in developing some special fastCGI or mod_php equivalent for running your java when you can use something standard and supported, e.g. a a different special-purpose apache httpd module written to serve your Java '/app/' running securely as a low priv user via AJP? LoadModule proxy_ajp_module modules/mod_proxy_ajp.so ProxyPass /app/ ajp://127.0.0.1:8009/app/ ProxyRequests Off #<Proxy *> # Order deny,allow # Deny from all # Allow from .example.com # </Proxy> ## NPM: see http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Performances#HModProxyAJPConfiguration ProxyPreserveHost On As apache/httpd must bind a privileged port (80), it must run as a privileged user. Because admins implicitly "trust" very little software that needs to run privileged, the actual choices of "trusted" implementations and configurations are limited. Given it's extensive history and broad support, apache httpd and most of it's modules are "trusted" by admins. One of the "trusted" modules typically available with apache (e.g. it's part of Fedora's 'httpd' rpms)♫ ♫ allows tomcat to run more securely as it's own "low privilege" user on a nonprivileged, private port. This follows the principle of least priviledge and reduction of overlapping concerns, low privilege users such as 'tomcat' running "open" and potentially dangerous code, should only be able to write to a very specific part of the filesystem and not access system-level and network resources.... All you need to do is enable AJP connector in tomcat: <Connector address="127.0.0.1" port="8009" URIEncoding="UTF-8" protocol="AJP/1.3"></Connector> Why is the jvm so slow at starting up? Both PHP and Python are byte code > compiled and run in a VM, but the runtime environments for both of these > languages start up almost instantly. Perhaps they use undump<http://www.tex.ac.uk/tex-archive/obsolete/support/undump/undump.SUN4.c>to get good startup performance? Java has introduced this facility as well. The inherent unportability of doing this (i've undumped plenty an emacsen and xlisp/winterp's in my time) is apparent in the spotty platform coverage: http://blog.headius.com/2009/01/my-favorite-hotspot-jvm-flags.html > -Xshare:dump can help improve startup performance on some installations. > When run as root (or whatever user you have the JVM installed as) it will > dump a shared-memory file to disk containing all of the core class data. > This file is much faster to load then re-verifying and re-loading all the > individual classes, and once in memory it's shared by all JVMs on the > system. Note that -Xshare:off, -Xshare:on, -Xshare:auto set whether "Class > Data Sharing" is enabled, and it's not available on the -server VM or on > 64-bit systems. Mac users: you're already using Apple's version of this > feature, upon which Hotspot's version is based. > If hosting services actually provided a specially undumped jvm, also set to "share", then multiple JVM's could be running in parallel, all sharing their huge libraries of code. Seems like this is the better solution for hosting Java -- pick a particular trusted baseline of libs that all apps/hosts/users will be using, and "preload" that into your java impl's "shared segment." Rather than reinventing some mechanism of regulating access or curtailing runaway peformance, you simply have a bunch of JVM's all running at a reasonable size, all sharing class files, and using the OS's built-in mechanisms to catch and signal runaway processes, audit usage, etc. Also by setting thread limits on individual JVM's, a single process spawning a lot of threads (perhaps runaway) doesn't swamp other JVM's from getting their fair share. -- Niels http://nielsmayer.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to [email protected] Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
