In Tomcat 7 the protection is provides is less than complete since the location where the JARs are copied to remains writable. Using unpackWARs=false and a read-only appBase defeats this particular attack vector in Tomcat 8. 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. Note that this discussions assumes a pre-existing application or Tomcat vulnerability that permits writing files into Tomcat's appBase.
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. The last of these work-arounds is often viewed as the simplest and would not be available if the unpackWARs option was removed. deploy an exploded directory rather than a WAR.
For performance reasons, any JARs in WEB-INF/lib were unpacked to the work directory and accessed from there. Prior to Tomcat 8 unpackWARs=false did not result in the web application running entirely from the WAR. 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. This page is intended to collect the reasons for and against the removal of this feature.
0 kommentar(er)
