Stuart Ballard wrote:
> Apparently I can't post this to -dev, because I'm not subscribed...
> could someone who is subscribed forward it there, because that's where
> it really belongs - thanks :)
>
Thanks for your suggestions, Stuart. I've cross-posted my reply to the
developer's list since I'm subscribed to both.
>
> -------- Original Message --------
> Subject: Suggestions for Apache JServ 1.1 (emulating SUexec)
> Date: Fri, 18 Jun 1999 22:20:01 -0400
> From: Stuart Ballard <[EMAIL PROTECTED]>
> Organization: Wuffies International
> To: [EMAIL PROTECTED]
>
> I posted this suggestion on -users way back in the days of 1.0 pre-beta
> snapshots, but since at the time the project was focussed on bugfixing,
> it was put off for later. Now that 1.0 is out, I thought this would be a
> good time to re-submit it for consideration. I've thought it through a
> lot since the original suggestion, too. The desired end-result is to
> allow for SUID execution of servlets with JServ without too much
> resource wastage, but I've broken it down into a number of independent
> parts which each could be implemented separately.
>
>From the descriptions here (and below), it sounds like you are after an
environment that an ISP might use to permit "occasional" servlet usage by
virtual web sites hosted on a server, using the OS level permissions to
limit what that user can do. That's a pretty useful thing to have, but I'm
pretty sure that a separate JVM per user is not going to be the right
approach -- unless you have ***very*** few users active at any one time --
to doing this.
A better long-term strategy, in my view, would be to take advantage of the
security sandbox capabilities of Java to limit the scope of servlets within
a particular servlet context (and assign one context to each "user"), so
that they can all run within a single JVM. This is a substantially more
scalable approach, and fits in to the longer term J2EE architecture that
was announced at JavaOne this week. In fact, future versions of the
servlet API are pretty much going to require an ability to do this kind of
thing.
Having such a capability will reduce or eliminate the need for several of
the techniques you propose. But I'd like to address a few of them
individually with other comments below.
>
> 1) Multiple automatic-mode engines. Allow the following syntax in
> httpd.conf:
> ApJServAutoEngine properties-file
> Multiple engines could be launched with different properties. This would
> completely supercede ApJServManual, which would be assumed if no engines
> were specified.
>
This would only work if you ran Apache itself as root. Processes running
under "nobody" or other non-privileged users are not allowed to create
processes under different usernames without going through a "su" type
login, which would invoke the user's startup shell.
>
> 2) Specification of user and group in jserv.properties. This would
> probably be one of the easiest to implement.
>
Easy to implement specifying them -- hard to use them :-).
>
> 3) Dynamic starting and stopping of JServ engines. This one has two
> parts:
> a) Stopping based on idleness. This could be configured in
> jserv.properties and would involve a criterion similar to "There are no
> active sessions and the engine has not been used in 20 minutes". The
> engine would then cleanly shut down. Of course the precise details of
> the criterion could be tweaked.
This kind of goes against the whole philosophy of servlet engines, which
are always there to be run. Wouldn't it be easier to just wrap your
servlets in a CGI script that starts and stops per request, instead?
>
> b) Starting up on demand. This is a little bit harder, because the
> engines may be running from somewhere completely different than the
> webserver. However, it could be done if a C-based "wrapper" engine
> grabbed the JServ port and dealt with starting it up if it wasn't
> already running. The wrapper would then forward all data sent to the
> port to the engine once it started. (the C wrapper would be what the
> ApJServAutoEngine line started; maybe even only one wrapper would be
> started for multiple AutoEngines, and monitor all their ports, but
> that's an implementation detail)
>
The startup would be feasible (except for the switching usernames part).
But, IMHO, the response time would be totally unacceptable to the person
viewing the site.
>
> 4) Optional, but nice: The ability to specify certain urls or url
> patterns (regexps?) that would trigger the auto-start even if they
> didn't actually use it. This might be used so that when a user visits
> the (static) main home page of a site, the engine would be started up
> and be ready for when he proceeds from there to the dynamic servlet
> pages that hang off it.
>
> Most of these enhancements make sense by themselves, but to clarify how
> they would be used together: For each user the sysadmin granted
> "servlet" privileges to, he would add an ApJServEngine line pointing to
> a properties file that specified the user's name and group. It would
> also specify dynamic startup and stopping so that there weren't 500 JVMs
> running at once (on the assumption that most users' home pages aren't
> going to be very high-volume, so this would save a lot of resources).
> This would give a nice way to do "SUExec" with Jserv, without incurring
> ridiculous overhead or re-inventing the wheel by re-implementing the OS
> security settings in Java.
>
Betting that your sites *won't* get hit very often seems like buying in to
a get rich quick scheme. The fact that you've got 500 users set up this
way means that at some time you *would* have very large numbers of JVMs
running. Unless you've configured your server to deal with it (mongo
amounts of memory and swap space), you've probably just crashed it. If you
have enough memory and swap space to run lots of JVMs, you might as well
just run them all the time anyway.
Hmm, if I knew your server was set up this way, it would be trivially
simple to create a "denial of service" attack on your server that touched
the home page of all 500 users within a few minutes and crashed your server
... and there's nothing you could do about it.
>
> What do people think?
>
> Stuart.
>
As I said above, I think a better strategy would be to sandbox servlet
contexts within a single JVM. This is the only way that you'll be able to
scale to very large numbers of "independent" users.
Craig McClanahan
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
READ THE FAQ!!!! <http://java.apache.org/faq/>
Archives and Other: <http://java.apache.org/main/mail.html/>
Problems?: [EMAIL PROTECTED]
