tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <>
Subject [Tomcat Wiki] Update of "RemoveUnpackWARs" by markt
Date Tue, 03 Mar 2015 14:23:49 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Tomcat Wiki" for change notification.

The "RemoveUnpackWARs" page has been changed by markt:

New page:
= Removing the unpackWARs feature =

This page is intended to collect the reasons for and against the removal of this feature.
The main purpose is to review use cases for using unpackWARs to ensure that a suitable alternative
would be available if the feature was removed but all arguments for and against the feature
are welcome.

== Background ==

Prior to Tomcat 8 unpackWARs=false did not result in the web application running entirely
from the WAR. For performance reasons, any JARs in WEB-INF/lib were unpacked to the work directory
and accessed from there. Tomcat 8 introduced a new resources implementation that did not perform
this unpacking. This had a significant (e.g. 3x to 10x slower application start) performance
impact - [[|Bug 57251]]. One of the options
suggested in the discussion on that bug was the removal of the unpackWARs feature.

== Use Cases for unpackWARs=false ==

=== Simpler deployment while Tomcat is stopped ===

If unpackWARs=true and a WAR is updated while Tomcat is stopped, Tomcat will not realise that
the unpacked directory structure is from an older version of the WAR and will continue to
use it. The current work-arounds are:
 * ensure that the exploded directory is deleted when the WAR is replaced
 * deploy an exploded directory rather than a WAR
 * use unpackWARs=false

The last of these work-arounds is often viewed as the simplest and would not be available
if the unpackWARs option was removed. Work is in progress to handle this use case within the
existing automatic deployment code so WARs updated while Tomcat is shut-down result in the
old directory being removed and the new WAR expanded in its place.

=== Security - make appBase read-only ===

Note that this discussions assumes a pre-existing application or Tomcat vulnerability that
permits writing files into Tomcat's appBase.

If the appBase is writeable by the Tomcat user and automatic deployment is enabled then it
makes it easier for an attacker to deploy a malicious application by placing it in the appBase.
Using unpackWARs=false and a read-only appBase defeats this particular attack vector in Tomcat
8. In Tomcat 7 the protection is provides is less than complete since the location where the
JARs are copied to remains writable.

The removal of unpackWARs would effectively require the deployment of web applications as
exploded directories if the appBase was to remain read-only to the Tomcat user.

=== Other use cases ===

Additional use cases welcome. Either directly on this page or via the users mailing list.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message