Re: [ProgSoc] Servlets

[Telford <telford@nospam.progsoc.uts.edu.au>]

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 only
read files which are world readable. Progsoc uses the suexec mechanism
for 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.policy
to 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 nothing
to 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.