Re: [ProgSoc] Servlets

[C Nguyen <C.Nguyen@nospam.uts.edu.au>]

Technically speaking, I don't think there's much difference between CGI 
and Servlet as Telford has rightly pointed out. 

However, there's a fact that we're all neglecting to recognise in this 
discussion is: there's a large community of Java Developers out there 
in the industry and probably a large proportion of Progsoc members are 
java developers themselves. Java is not the greatest language ever ( 
and probably there's no language that is the greatest anyways ) but it 
has proven itself as a language designed with the net ( and Internet ) 
in mind. So, why not use it for internet applications.

CGI is OK but most CGI programs are written in scripting languages or C 
that don't offer the benefits of OO programming that language like Java 
does. Well, I can certainly write CGI using C++ but again it's not 
as "net oriented" as java.


----- Original Message -----
From: Telford <telford@nospam.progsoc.uts.edu.au>
Date: Sunday, February 4, 2001 8:52 pm
Subject: Re: [ProgSoc] Servlets

> On Fri, Feb 02, 2001 at 09:59:24AM +0000, Greg Kopff wrote:
> > At 08:34 AM 2/2/01 +1100, you wrote:
> > >You can't just blithely say there are no security problems because
> > >the JVM takes care of it... what about the points that I was 
> asking?> >* How does a servlet get write access local files (if at 
> all)?> 
> > The Java Virtual Machine allows you to assign permissions to 
> various things
> > like disk access.  Attempting to break a permission results in a 
> run-time
> > exception.  The default policy file is probably <jdk
> > dir>/jre/lib/security/java.policy.  By default, you have read 
> and write
> > access to the local filesystem.
> > 
> > >* How to control which local files it can access?
> > 
> > Again, the security policy.  And then there's the underlying 
> OS's file
> > system permissions ...
> 
> Well I don't fully understand the java.policy file but I do understand
> that apache will generally do file access as ``nobody'' so it will 
> onlyread files which are world readable. Progsoc uses the suexec 
> mechanismfor CGIs which means that telford's CGI programs run as 
> ``telford'' and
> can access files that only I would access.
> 
> If I want to write a record from a CGI script to a file in my home
> directory then I don't want to make that file world writable 
> because then
> anyone can fiddle with it and bypass my CGI. Using suexec I can make
> the file writable only by myself and then the CGI still works but
> no one can do dodgy stuff.
> 
> When it runs that JVM, will it run as nobody, or will it have an
> equivalent to suexec or will it run as root and then depend on 
> java.policyto restrict it?
> 
> > >* How can it do mysql queries?
> > 
> > You use the Java Database Connectivity stuff.  Never used it 
> myself though.
> >  Databases are slow and ugly.
> > 
> > >* Is it possible for a local user to read the servlet code
> > >  and extract mysql passwords?
> > 
> > Servlets are like other Java programs.  You take your source and 
> compile it
> > to a class file.  So, just like a CGI, one could read passwords by:
> >  - looking at the source
> >  - running strings on the binary
> 
> With a CGI I would set world execute permission but no world
> read permission ( -rwx--x--x ) which means that no one is allowed
> to strings the binary but they can run the binary. The only
> problem is that they can strace the program while it runs but
> the program can check for that by looking at what UID it is
> running as.
> 
> The apache suexec mechanism is kind of rooted in this respect;
> using a suid bit prevents strace and provides the effect of suexec
> with less risks. Apache suexec will refuse to run any program
> with suid bit set (won't even run it as nobody!) and you can't
> opt-out of suexec on a user-by-user basis.
> 
> Of course, the suid bit doesn't work for scripts.
> 
> > >So how is this different from a regular CGI?
> > 
> > A regular CGI is forked and execed.  However, when a servlet is 
> invoked the
> > first time, the class file(s) are dynamically loaded by the JVM. 
> Each
> > subsequent request is therefore much faster because invocation 
> is simply a
> > method call to the now resident class.  Servlets are faster than
> > conventional CGIs because a servlet runs in the context of a 
> thread, or
> > light-weight process, which in many operating systems permit 
> much faster
> > context switching than heavy-weight processes.
> 
> Ummm, I'm yet to be convinced of the advantage of threads...
> in linux the context switch overhead is basically the same between
> threads and processes, possibly some small advantage is gained by
> not reprogramming the MMU registers, I doubt anyone could measure it.
> 
> The issue of class caching in the server is a bit tricky too,
> with CGI programs that are proper compiled binaries, you get
> caching of the shared object libraries and also disk-cache for
> the executable file. I wonder if the JVM overhead is actually
> any smaller than the fork overhead (especially when linux has the
> lowest fork overhead of just about any multitasking OS).
> 
> With CGI programs that are perl scripts, it is obvious that the
> author is more interested in terse code than high performance.
> 
> Besides, if it is an issue of performance then the time is better
> spent getting the SS2000 up and running which will provide more
> boost to performance than anything else.
> 
> > >My understanding is that the client (i.e. browser) sends a
> > >URL along with either GET or POST data (containing form parameters)
> > >to the web server which then runs some program to process
> > >the data and return HTML back to the browser. This is what
> > >CGI programs do and I'm wondering if there is anything different
> > >about servlets which makes them need to be handled differently.
> > 
> > Yes, a servlet is much like a CGI - however it is more tightly 
> integrated> with the webserver/servlet engine.  Instead of having 
> to do lots of fiddly
> > string manipulations on environment variables or command line 
> arguments> passed to a CGI process (with the inherent buffer 
> overrun implications),
> > servlets enable you to access all relevant details associated 
> with the
> > request via nicely encapsulated objects via accessor methods 
> (giving you
> > type safety).
> 
> Having the IO nicely organised can be handy, then again there is 
> nothingto stop you using a library in any programming language and 
> the library
> can encapsulate the input process any way you like.
> 
> > >Well if you want Tomcat then we have to compile it together with
> > > (...)
> > 
> > Alternatively, there is the W3 consortium's Jigsaw Webserver and 
> Servlet> Engine which is all written in Java.  See 
> http://www.w3.org/jigsaw - then
> > there's no need to modify apache.  Also, you get the full 
> benefits of
> > running servlets without apache's bloat.
> 
> I'm happy for people to try it.
> 
> -- 
> S1G: 18723354 seconds remaining			- Tel
> -
> You are subscribed to the progsoc mailing list. To unsubscribe, 
> send a
> message containing "unsubscribe" to progsoc-
> request@nospam.progsoc.uts.edu.au.If you are having trouble, ask owner-
> progsoc@nospam.progsoc.uts.edu.au for help.
> 

-
You are subscribed to the progsoc mailing list. To unsubscribe, send a
message containing "unsubscribe" to progsoc-request@nospam.progsoc.uts.edu.au.
If you are having trouble, ask owner-progsoc@nospam.progsoc.uts.edu.au for help.