[Tomcat Wiki] Update of "RemoveUnpackWARs" by markt

[Apache Wiki <wi...@apache.org>]

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:
https://wiki.apache.org/tomcat/RemoveUnpackWARs

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 - [[https://bz.apache.org/bugzilla/show_bug.cgi?id=57251|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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org