Bug 50984 - Manager application fails to report stranded artifacts when undeploying
Summary: Manager application fails to report stranded artifacts when undeploying
Status: RESOLVED FIXED
Alias: None
Product: Tomcat 7
Classification: Unclassified
Component: Manager (show other bugs)
Version: 7.0.11
Hardware: PC Linux
: P2 major (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-03-28 03:42 UTC by Francis Galiegue
Modified: 2011-03-30 13:40 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Francis Galiegue 2011-03-28 03:42:36 UTC
[NOTE: this is tomcat 7.0.11, not 7.0.10, but the version is not given as a choice, I therefore file it as 7.0.10, which I suspect has the same bug]

Scenario:

* tomcat starts, as user u1, with only the manager application in place;
* it is configured as to not deploy automatically;
* user u1 copies a webapp tree into $CATALINA_HOME/webapps, which it
can since it has write/execute access to this directory;
* the manager webapp is called to deploy that new web application;
* [in between, credentials on the deployed webapp directory are
changed so that user u1 cannot remove the webapp at all]
* the manager webapp is called to undeploy that application, BUG: it
answers OK, but it is not.

The manager webapp documentation explicitly states that undeploying an
application means that the webapp tree is removed - but of course, in
this case it isn't. Use case below, where $CATALINA_HOME/webapps is a symlink to /var/lib/o3/tomcat/installs:

----
# Only manager webapp running initially
[o3@tomcat-r8 cockpit]$ wget -O - -q --http-user=tomcat
--http-password=tomcat  http://localhost:8080/manager/text/list|sed 1d
/manager:running:6:/usr/share/tomcat7/webapps/manager
# webapp tree is created by other means. Now deploying the application:
[o3@tomcat-r8 cockpit]$ wget -O - -q --http-user=tomcat --http-password=tomcat http://localhost:8080/manager/text/deploy'?path=/cockpit&war=file:/var/lib/o3/tomcat/installs/cockpit'
OK - Deployed application at context path /cockpit
[...]
# In another terminal:
[root@tomcat-r8 installs]# pwd
/var/lib/o3/tomcat/installs
# All files are created with umask 022. Just change the owner:
[root@tomcat-r8 installs]# chown -R root.root cockpit/
[...]
# Back to the first terminal:
[o3@tomcat-r8 cockpit]$ wget -O - -q --http-user=tomcat --http-password=tomcat
http://localhost:8080/manager/text/undeploy?path=/cockpit
OK - Undeployed application at context path /cockpit
# Here is the bug: even though the command returns OK, the tree still exists.
# The webapp is stopped, but it is not undeployed.
[o3@tomcat-r8 cockpit]$ wget -O - -q --http-user=tomcat
--http-password=tomcat  http://localhost:8080/manager/text/list|sed 1d
/manager:running:9:/usr/share/tomcat7/webapps/manager  
/cockpit:stopped:0:cockpit
# Listing the contents of $CATALINA_HOME/webapps, we see that the tree is still 
# there:
[o3@tomcat-r8 cockpit]$ ls /var/lib/o3/tomcat/installs
cockpit
----

The documentation states:

----
WARNING - This command will delete any web application artifacts that exist within appBase directory (typically "webapps") for this virtual host. This will
delete the the application .WAR, if present, the application directory resulting either from a deploy in unpacked form or from .WAR expansion as well as the XML Context definition from $CATALINA_BASE/conf/[enginename]/[hostname]/ directory.
----

This turns out to be false in this case. While the application is stopped, the web application artifacts are NOT removed. The
undeploy command should have failed with, say "FAIL - context was stopped but some articats remain, check access rights". What's more, the logs
don't mention that the webapp tree has failed to be removed at all.

If I chown back the webapp tree to its rightful owner, then the webapp
is indeed undeployed as intended: all artifacts are destroyed.

The culprit code seems to be at org/apache/catalina/manager/ManagerServlet.java, methods undeploy() and undeployDir(). Both use the .delete() method of File objects, but fail to check their return code.
Comment 1 Mark Thomas 2011-03-28 04:16:20 UTC
Version added to database and issue updated.
Comment 2 Mark Thomas 2011-03-30 13:40:09 UTC
Fixed in 7.0.x and will be included in 7.0.12 onwards.