Edoardo Panfili wrote:
Il 19/10/13 14:21, Martin Gainty ha scritto:





Date: Sat, 19 Oct 2013 10:23:11 +0200
From: edoa...@aspix.it
To: users@tomcat.apache.org
Subject: Re: can't connect to manager application

Il 19/10/13 00:24, Mark Eggers ha scritto:
On 10/18/2013 3:18 PM, André Warnier wrote:
Edoardo Panfili wrote:
Il 17/10/13 18:45, Edoardo Panfili ha scritto:
My Tomcat (7.0.42) is listening on port 7080 and I have this
conf/tomcat-users.xml in (production server)

-------
<tomcat-users>
<role rolename="manager-script"/>
<user username="myname" password="pwd"
roles="manager-script,manager-gui,manager-jmx"/>
</tomcat-users>
----------
if I use

curl -u myname:pwd
http://localhost:7080/manager/text/reload?path=/myApplication

the response is--------------------------
<h1>404 Not found</h1>
<p>
The page you tried to access
(/manager/text/reload)
does not exist.
</p>
<p>
The Manager application has been re-structured for Tomcat 7
onwards
and some
of URLs have changed. All URLs used to access the Manager
application should
now start with one of the following options:
</p>
<ul>
<li>/manager/html for the HTML GUI</li>
<li>/manager/text for the text interface</li>
<li>/manager/jmxproxy for the JMX proxy</li>
<li>/manager/status for the status pages</li>
</ul>
<p>
Note that the URL for the text interface has changed from
&quot;/manager&quot; to
&quot;/manager/text&quot;.
</p>
<p>
You probably need to adjust the URL you are using to access the
Manager
application. However, there is always a chance you have found a
bug
in the
Manager application. If you are sure you have found a bug, and
that
the bug
has not already been reported, please report it to the Apache
Tomcat team.
</p>
---------------------------------------------------------


Installation step by step:

Unpack new download from tomcat.apache.org

1- set users
<tomcat-users>
<user username="edoardo" password="pwd"
roles="manager-script,manager-gui,manager-jmx,other"/>
</tomcat-users>

then reload tomcat
$curl -u edoardo:pwd
http://localhost:8080/manager/text/reload?path=/examples
OK - Reloaded application at context path /examples


2- copy myApplication from production server
copy configuration file ($tomcat/Catalina/localhost/myApplication.xml)
from production server
stop & start tomcat

$curl -u edoardo:pwd
http://localhost:8080/manager/text/reload?path=/myApplication
OK - Reloaded application at context path /myApplication


3- first modify to server.xml
shutdown tomcat
modify server.xml
<Connector port="8080" protocol="HTTP/1.1"
becomes
<Connector port="9080" protocol="HTTP/1.1"

start then curl again
all well


4- second modify to server.xml
<Host name="localhost" appBase="webapps"
unpackWARs="true" autoDeploy="true">
becomes
<Host name="localhost" appBase="webapps"
unpackWARs="true" autoDeploy="true" deployXML="false">

stop-start

$curl -u edoardo:pwd
http://localhost:9080/manager/text/reload?path=/myApplication
javax.servlet.ServletException: Error instantiating servlet class
org.apache.catalina.manager.ManagerServlet
[...]

$curl -u edoardo:pwd
http://localhost:9080/manager/text/reload?path=/myApplication
the same error reported in the initial post (above)



deployXML="false" is recommended at
http://tomcat.apache.org/tomcat-7.0-doc/config/host.html and useful
for me.

One big difference that I see when deployXML="false", is that this file :
(catalina_base)/webapps/myApplication/META-INF/context.xml
is no longer being parsed,
and instead this file is parsed :
$tomcat/Catalina/localhost/myApplication.xml
when you reload your app.
What is the content of that file ?

 From the last log file that was posted, these context files are pretty
broken (although myApplication.xml only had the magic debug attribute set).


- unpack tomcat
- add an user in tomcat-users.xml
- modify server.xml adding deployXML="false" to Host
<Host name="localhost" appBase="webapps"
unpackWARs="true" autoDeploy="true" deployXML="false">
- use manager application via curl
$ curl -u user:pwd http://localhost:8080/manager/text/reload?path=/example

error page.

# cat manager.2013-10-19.log
19-ott-2013 10.16.17 org.apache.catalina.core.ApplicationContext log
INFO: Marking servlet Manager as unavailable
19-ott-2013 10.16.17 org.apache.catalina.core.StandardWrapperValve invoke
GRAVE: Allocate exception for servlet Manager
java.lang.SecurityException: Restricted (ContainerServlet) class
org.apache.catalina.manager.ManagerServlet
at
org.apache.catalina.core.DefaultInstanceManager.checkAccess(DefaultInstanceManager.java:538)
at
org.apache.catalina.core.DefaultInstanceManager.loadClassMaybePrivileged(DefaultInstanceManager.java:511)
at
org.apache.catalina.core.DefaultInstanceManager.newInstance(DefaultInstanceManager.java:137)
at
org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1144)
at
org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:865)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:136)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:611)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:953)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)
at
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1023)
at
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589)
at
org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:636)

MG>run catalina with debug AND securityManager enabled
MG>catalina<.bat/sh> debug -security //Debug Catalina with a security manager

MG>Ensure Security listener is enabled in server.xml
MG><Listener className="org.apache.catalina.security.SecurityListener" />

MG>check permissions setup for "securityManager" in /conf/catalina.policy
MG>// catalina.policy - Security Policy Permissions for Tomcat 7
//
// This file contains a default set of security policies to be enforced (by the // JVM) when Catalina is executed with the "-security" option. In addition // to the permissions granted here, the following additional permissions are
// granted to each web application:
//
// * Read access to the web application's document root directory
// * Read, write and delete access to the web application's working directory
// These permissions apply to javac
grant codeBase "file:${java.home}/lib/-" {
         permission java.security.AllPermission;
};
// These permissions apply to all shared system extensions
grant codeBase "file:${java.home}/jre/lib/ext/-" {
         permission java.security.AllPermission;
};
// These permissions apply to javac when ${java.home] points at $JAVA_HOME/jre
grant codeBase "file:${java.home}/../lib/-" {
         permission java.security.AllPermission;
};
// These permissions apply to all shared system extensions when
// ${java.home} points at $JAVA_HOME/jre
grant codeBase "file:${java.home}/lib/ext/-" {
         permission java.security.AllPermission;
};

MG>make sure ALL of these grants in catalina.policy are enabled (and not commented out or deleted)
MG>bounce TC and report back

permissions OK.(none modified)
Security listener in server.xml in now enabled
$ export JAVA_HOME=/usr/lib/jvm/java-6-openjdk/


$tomcat/bin/catalina.sh debug -security
Using CATALINA_BASE:   /usr/local/tomcat7
Using CATALINA_HOME:   /usr/local/tomcat7
Using CATALINA_TMPDIR: /usr/local/tomcat7/temp
Using JAVA_HOME:       /usr/lib/jvm/java-6-openjdk/
Using CLASSPATH: /usr/local/tomcat7/bin/bootstrap.jar:/usr/local/tomcat7/bin/tomcat-juli.jar
Using Security Manager
Initializing jdb ...
 > run
run org.apache.catalina.startup.Bootstrap start
Set uncaught java.lang.Throwable
Set deferred uncaught java.lang.Throwable
 >
VM Started: 19-ott-2013 15.33.07 org.apache.catalina.core.AprLifecycleListener init INFO: The APR based Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: /usr/lib/jvm/java-6-openjdk/jre/lib/amd64/server:/usr/lib/jvm/java-6-openjdk/jre/lib/amd64:/usr/lib/jvm/java-6-openjdk/jre/../lib/amd64:/usr/java/packages/lib/amd64:/usr/lib/jni:/lib:/usr/lib java.lang.Error: Start attempted while running as user [root]. Running Tomcat as this user has been blocked by the Lifecycle listener org.apache.catalina.security.SecurityListener (usually configured in CATALINA_BASE/conf/server.xml) at org.apache.catalina.security.SecurityListener.checkOsUser(SecurityListener.java:154) at org.apache.catalina.security.SecurityListener.doChecks(SecurityListener.java:142) at org.apache.catalina.security.SecurityListener.lifecycleEvent(SecurityListener.java:63) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119) at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90) at org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:402)
    at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:99)
    at org.apache.catalina.startup.Catalina.load(Catalina.java:640)
    at org.apache.catalina.startup.Catalina.load(Catalina.java:665)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:616)
    at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:281)
    at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:455)

The application exited
root@virtual-vnr:/usr/local/tomcat7/logs#


the same using jdk1.7.0_45 from Oracle.


As posted by Konstantin before, your problem has nothing to do with the Java 
Security manager.
But the problem that ou are having here is because you run Tomcat as user root. The SM doesn't like that. That is why "jsvc" exists. It will allow the process to open a listening port < 1024, but Tomcat itself will not run as root. Running a webserver as root is dangerous : it has too many privileges; if it gets broken in, your whole system is open to the attacker.
One thing at a time.  For now, forget about the Security Manager.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to