You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Nicholas Orr <Ni...@mim.com.au> on 2002/09/10 03:19:15 UTC

RE: Tomcat scalability question

Hi,

Just a suggestion.

Why not use Apache to take care of all the security? Ie have home
directories for each user and only the user has access to his/her home
directory, then apache can use a standard like http://localhost/~user and
everything is sepearate. It would be a lot easier to Administer. When you
delete or add new user they just have a webapps folder and it goes from
there.
Ie user/
     webapps/
       context1/
         index.jsp
         WEB-INF/
           classes/
             home.class
           lib/
             tools.jar
           web.xml

       context2/
         index.jsp
         WEB-INF/
           classes/
             cool.class
           lib/
             goodstuff.jar
           web.xml

I don't know if that would work. It might need to to be reorganised. But a
system like this would be a lot better than administering a 500+ entry xml
file.

Oh well some other people will have more of an idea if this is possible. I
know Apache can have the ~user bit and it just maps to home directories
under /home/usr/username.

Nicholas Orr

-----Original Message-----
From: Pat Schaider [mailto:doctor@wt.net] 
Sent: Tuesday, 10 September 2002 4:08 PM
To: tomcat-user@jakarta.apache.org
Subject: Tomcat scalability question


Hello all --

I have a configuration problem on my setup of Tomcat (v 4.0.3).  I am
managing this machine for my university's CS department, so there are issues
of security that must be followed, namely that students should not be able
to view each others source code (== cheating).  We are using the security
manager to enforce this (so one context cannot open files in another).

Less than 5% of the pages on the system are static, so we are using Tomcat
in standalone mode on a Linux system.  We have made contexts for each user
so that we can override the location of home directories, log files, etc.
Note that students do not have logins on this machine; their Tomcat-related
files are exported to student use machines.  See the bottom of this email
for pertinent config info.

The server starts up correctly (./startup.sh -security) and deploys and
serves the webapps fine.  But here's the problem: when a user decides to
make a new jsp file, Tomcat cannot compile or process that new file. 
The old files in the directory still display properly; Tomcat gives a
Permission Denied error citing the working directory version of the new file
in question.

-> message
/usr/local/jakarta-tomcat-4.0.3/work/localhost/user/tomcat/webapps/jsp/grade
rFiles/graderC$jsp.java (Permission denied)

Here's some site-specific config info that will be useful. Tomcat version:
4.0.3 Standalone from binaries There are about 250 contexts that get loaded
when the server starts.  A `ps aux` listing shows about 500 processes
associated with Tomcat running.  The machine is a P3-800 with 512 MB of
memory, and does not have any other heavy services running on it, so Tomcat
has full run of the box.  If you need more info for diagnosis, email me and
I will provide it.

Does anyone have experience setting up a system along these lines?  I
realize it's probably an extension of what Tomcat is supposed to be used for
with all the different contexts, but there has to be a way!  Any help is
appreciated.

server.xml without comments
===========================
<Server port="8005" shutdown="SHUTDOWN" debug="0">
  <Service name="Tomcat-Standalone">
    <Connector
	className="org.apache.catalina.connector.http.HttpConnector"
	port="8080" minProcessors="5" maxProcessors="75"
	enableLookups="true" redirectPort="8443"
	acceptCount="10" debug="0" connectionTimeout="60000"/>

    <Engine name="Standalone" defaultHost="localhost" debug="0">

      <Logger className="org.apache.catalina.logger.FileLogger"
              prefix="catalina_log." suffix=".txt"
              timestamp="true"/>

      <Host name="localhost" debug="0" appBase="webapps" 
	unpackWARs="true">

        <!-- user1 -->
        <Context path="/user1" docBase="/tomcat/user1"
         debug="0" reloadable="true" crossContext="false">
        </Context>
        <!-- user2 -->
        <Context path="/user2" docBase="/tomcat/user2"
         debug="0" reloadable="true" crossContext="false">
        </Context>

      </Host>
    </Engine>
  </Service>
</Server>
===========================

Thanks in advance for any help you can provide.  Apologies for the lengthy
email.

Pat Schaider
doctor {at} wt {dot} net

--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>


**********************************************************************
The information contained in this e-mail is confidential and is
intended only for the use of the addressee(s).
If you receive this e-mail in error, any use, distribution or
copying of this e-mail is not permitted. You are requested to
forward unwanted e-mail and address any problems to the
MIM Holdings Limited Support Centre.

For general enquires:	++61 7 3833 8000
Support Centre e-mail:	supportcentre@mim.com.au
Support Centre phone:  	Australia 1800500646
        				International ++61 7 38338042
**********************************************************************


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


RE: Tomcat scalability question

Posted by Pat Schaider <do...@wt.net>.
I should clarify.  "Security" in this case means "a student should not
be able to view the source code of another student."  Because we are
exporting the files but they still need to be accessible by Tomcat, each
user directory is 570 tomcat:user and all files inside are world
readable.  This allows the files to be secure from the perspective of
the filesystems on both the exporting and mounting machines but still be
all readable by Tomcat.  

However, another way a student could look at other files is by using a
BufferedReader within a servlet/jsp and simply viewing/saving the
contents.  Since Tomcat is running as the tomcat user and not them, it
has access to the files.  This is something that the Tomcat security
manager should take care of, enforcing the boundaries between the
students' directories that all exist at the same logical level.  I don't
think Apache can make the distinction between the files that a
servlet/jsp is opening in this instance if Tomcat has unrestricted
access between all contexts.

If I am wrong in this respect, please correct me.  I would love a simple
solution.

(As far as the server.xml goes, I have it all scripted with the data
coming from databases, so it's relatively easy to make a version of the
file...)

Pat Schaider

On Mon, 2002-09-09 at 20:19, Nicholas Orr wrote:
> Hi,
> 
> Just a suggestion.
> 
> Why not use Apache to take care of all the security? Ie have home
> directories for each user and only the user has access to his/her home
> directory, then apache can use a standard like http://localhost/~user and
> everything is sepearate. It would be a lot easier to Administer. When you
> delete or add new user they just have a webapps folder and it goes from
> there.
> Ie user/
>      webapps/
>        context1/
>          index.jsp
>          WEB-INF/
>            classes/
>              home.class
>            lib/
>              tools.jar
>            web.xml
> 
>        context2/
>          index.jsp
>          WEB-INF/
>            classes/
>              cool.class
>            lib/
>              goodstuff.jar
>            web.xml
> 
> I don't know if that would work. It might need to to be reorganised. But a
> system like this would be a lot better than administering a 500+ entry xml
> file.
> 
> Oh well some other people will have more of an idea if this is possible. I
> know Apache can have the ~user bit and it just maps to home directories
> under /home/usr/username.
> 
> Nicholas Orr
> 
> -----Original Message-----
> From: Pat Schaider [mailto:doctor@wt.net] 
> Sent: Tuesday, 10 September 2002 4:08 PM
> To: tomcat-user@jakarta.apache.org
> Subject: Tomcat scalability question
> 
> 
> Hello all --
> 
> I have a configuration problem on my setup of Tomcat (v 4.0.3).  I am
> managing this machine for my university's CS department, so there are issues
> of security that must be followed, namely that students should not be able
> to view each others source code (== cheating).  We are using the security
> manager to enforce this (so one context cannot open files in another).
> 
> Less than 5% of the pages on the system are static, so we are using Tomcat
> in standalone mode on a Linux system.  We have made contexts for each user
> so that we can override the location of home directories, log files, etc.
> Note that students do not have logins on this machine; their Tomcat-related
> files are exported to student use machines.  See the bottom of this email
> for pertinent config info.
> 
> The server starts up correctly (./startup.sh -security) and deploys and
> serves the webapps fine.  But here's the problem: when a user decides to
> make a new jsp file, Tomcat cannot compile or process that new file. 
> The old files in the directory still display properly; Tomcat gives a
> Permission Denied error citing the working directory version of the new file
> in question.
> 
> -> message
> /usr/local/jakarta-tomcat-4.0.3/work/localhost/user/tomcat/webapps/jsp/grade
> rFiles/graderC$jsp.java (Permission denied)
> 
> Here's some site-specific config info that will be useful. Tomcat version:
> 4.0.3 Standalone from binaries There are about 250 contexts that get loaded
> when the server starts.  A `ps aux` listing shows about 500 processes
> associated with Tomcat running.  The machine is a P3-800 with 512 MB of
> memory, and does not have any other heavy services running on it, so Tomcat
> has full run of the box.  If you need more info for diagnosis, email me and
> I will provide it.
> 
> Does anyone have experience setting up a system along these lines?  I
> realize it's probably an extension of what Tomcat is supposed to be used for
> with all the different contexts, but there has to be a way!  Any help is
> appreciated.
> 
> server.xml without comments
> ===========================
> <Server port="8005" shutdown="SHUTDOWN" debug="0">
>   <Service name="Tomcat-Standalone">
>     <Connector
> 	className="org.apache.catalina.connector.http.HttpConnector"
> 	port="8080" minProcessors="5" maxProcessors="75"
> 	enableLookups="true" redirectPort="8443"
> 	acceptCount="10" debug="0" connectionTimeout="60000"/>
> 
>     <Engine name="Standalone" defaultHost="localhost" debug="0">
> 
>       <Logger className="org.apache.catalina.logger.FileLogger"
>               prefix="catalina_log." suffix=".txt"
>               timestamp="true"/>
> 
>       <Host name="localhost" debug="0" appBase="webapps" 
> 	unpackWARs="true">
> 
>         <!-- user1 -->
>         <Context path="/user1" docBase="/tomcat/user1"
>          debug="0" reloadable="true" crossContext="false">
>         </Context>
>         <!-- user2 -->
>         <Context path="/user2" docBase="/tomcat/user2"
>          debug="0" reloadable="true" crossContext="false">
>         </Context>
> 
>       </Host>
>     </Engine>
>   </Service>
> </Server>
> ===========================
> 
> Thanks in advance for any help you can provide.  Apologies for the lengthy
> email.
> 
> Pat Schaider
> doctor {at} wt {dot} net
> 
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> 
> 
> **********************************************************************
> The information contained in this e-mail is confidential and is
> intended only for the use of the addressee(s).
> If you receive this e-mail in error, any use, distribution or
> copying of this e-mail is not permitted. You are requested to
> forward unwanted e-mail and address any problems to the
> MIM Holdings Limited Support Centre.
> 
> For general enquires:	++61 7 3833 8000
> Support Centre e-mail:	supportcentre@mim.com.au
> Support Centre phone:  	Australia 1800500646
>         				International ++61 7 38338042
> **********************************************************************
> 
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
> 


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>