Bug 61154 - The manager applications don't start when using the Security Manager
Summary: The manager applications don't start when using the Security Manager
Alias: None
Product: Tomcat 8
Classification: Unclassified
Component: Manager (show other bugs)
Version: 8.5.x-trunk
Hardware: PC Linux
: P2 normal (vote)
Target Milestone: ----
Assignee: Tomcat Developers Mailing List
Depends on:
Reported: 2017-06-04 14:17 UTC by Coty Sutherland
Modified: 2019-03-11 04:57 UTC (History)
0 users


Note You need to log in before you can comment on or make changes to this bug.
Description Coty Sutherland 2017-06-04 14:17:31 UTC
With a vanilla install the admin applications fail to deploy if you start using the Security Manager. To resolve the issue you can move the context.xml from the webapps into the conf/[Engine]/[Host] directory renaming them to match the webapp. Is there some reason we don't inherently trust the manager webapps? Is this behavior on purpose?

To reproduce:

1) Download, unzip, and start Tomcat

$ wget http://apache.mesi.com.ar/tomcat/tomcat-8/v8.5.15/bin/apache-tomcat-8.5.15.tar.gz
$ tar xvf apache-tomcat-8.5.15.tar.gz
$ pushd apache-tomcat-8.5.15
$ bin/catalina.sh start -security

2) Check the log for the following exception (stacks shortened for brevity and excludes host-manager exception):

04-Jun-2017 10:15:30.344 SEVERE [localhost-startStop-1] org.apache.catalina.startup.HostConfig.deployDirectory The web application with context path [/manager] was not deployed because it contained a deployment descriptor [/apache-tomcat-8.5.15/webapps/manager/META-INF/context.xml] which may include configuration necessary for the secure deployment of the application but processing of deployment descriptors is prevented by the deployXML setting of this host. An appropriate descriptor should be created at [/apache-tomcat-8.5.15/conf/Catalina/localhost/manager.xml] to deploy this application.
04-Jun-2017 10:15:30.376 SEVERE [localhost-startStop-1] org.apache.catalina.core.ContainerBase.addChildInternal ContainerBase.addChild: start: 
 org.apache.catalina.LifecycleException: Failed to start component [/manager]
    at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:167)
Caused by: org.apache.catalina.LifecycleException: Failed to process either the global, per-host or context-specific context.xml file therefore the [/manager] Context cannot be started.
    at org.apache.catalina.startup.FailedContext.startInternal(FailedContext.java:199)
    at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
    ... 14 more

04-Jun-2017 10:15:30.377 SEVERE [localhost-startStop-1] org.apache.catalina.startup.HostConfig.deployDirectory Error deploying web application directory [/apache-tomcat-8.5.15/webapps/manager]
 java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: Failed to start component [/manager]
    at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:756)
Comment 1 Mark Thomas 2017-06-08 20:20:32 UTC
The RemoteAddrVale we can replace with the equivalent filter. The privileged attribute is trickier. Still thinking about that.
Comment 2 Konstantin Kolinko 2017-06-08 22:30:31 UTC
Two ideas:

A. Move manager and host-manager out of webapps,
and deploy them via a context file?

- It was like that in Tomcat 5.5

- I use this configuration when running with separate CATALINA_BASE and CATALINA_HOME, and documented the recipe in RUNNING.txt


B. Implement some permission that whitelists the use of context.xml in manager, host-manager?

The default catalina.policy already has special permissions for manager,
thus this web application already has special configuration there.

Comment 3 Mark Thomas 2017-06-09 08:49:02 UTC
I was heading in the direction of B. However, I don't see a simple solution that works equally well with and without a SecurityManager.

My thinking so far has reached the point of wondering if the privileged flag on the context makes any sense at all when not running under a SecuirtyManager.
Comment 4 Konstantin Kolinko 2017-06-09 14:56:03 UTC
(In reply to Mark Thomas from comment #3)
> My thinking so far has reached the point of wondering if the privileged flag
> on the context makes any sense at all when not running under a
> SecurityManager.

[1] http://tomcat.apache.org/tomcat-8.5-doc/config/context.html#Common_Attributes

AFAIK, the "privileged" flag on Context has two effects [1]:

a) allow this context to use container servlets

b) change the context's parent class loader to be the Server class loader rather than the Shared class loader

Anything else?

I think that the permission to use servlets ("a)") does not make sense when running without SecurityManager.

An idea: replace it with an explicit Permission to access specific container servlets? Manager web application needs only a subset of those servlets.

The classloader hierarchy effect ("b)") is important regardless of SecurityManager, but there is no actual need for it.
Comment 5 Mark Thomas 2017-06-09 16:30:21 UTC
b) is required if the class loader hierarchy is expanded to the 5.5.x structure where common, shared and catalina class loaders are all separate.
Comment 6 Mark Thomas 2017-06-11 15:51:57 UTC
Having explored lots of different options, the cleanest solution I could find was using a custom permission to override deployXML for a specific Context when running under a security manager.

Fixed in:
- trunk for 9.0.0.M22 onwards
- 8.5.x for 8.5.16 onwards
- 8.0.x for 8.0.45 onwards
- 7.0.x for 7.0.79 onwards