Re: Websocket semaphore lock on close() blocks all tomcat threads
On 14/07/2020 21:08, Mark Thomas wrote: > On 14/07/2020 20:57, Sridhar Rao wrote: >> >> We notice a behavior with tomcat where it becomes unresponsive and all >> http threads go into a timed wait state and the node becomes unresponsive. >> >> Tomcat Version: 8.5.47 > > > >> Could this be a tomcat defect? > > Possibly. > > Let me take a look. I don't recall anything along these lines being > fixed since 8.5.47 but there might be. Yep. Looks like an issue in all current versions. Fixed for 10.0.x with back-ports to follow shortly. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Websocket semaphore lock on close() blocks all tomcat threads
On 14/07/2020 20:57, Sridhar Rao wrote: > > We notice a behavior with tomcat where it becomes unresponsive and all > http threads go into a timed wait state and the node becomes unresponsive. > > Tomcat Version: 8.5.47 > Could this be a tomcat defect? Possibly. Let me take a look. I don't recall anything along these lines being fixed since 8.5.47 but there might be. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat can't find suitable driver for mysql
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jon, On 7/13/20 19:27, jonmcalexan...@wellsfargo.com.INVALID wrote: > Yes, that also works, however it's just as easy to do that in a > setenv.sh file in the bin folder. Its actually much better to do it in setenv.sh for a few reasons: 1. /etc/environment is not exactly a standard; it appears that it's a PAM feature and not part of any stock *NIX system 2. /etc/environment sets that variable for all users, for all processes (if it even does that) 3. /etc/environment would likely not affect any system-launched services (e.g. from /etc/init.d / systemd / whatever) 4. Tomcat clears any CLASSPATH environment variable under normal circumstances; anyone else looking at your environment may be surprised by what you have done setenv.sh aside, there is always this: 5. Dropping your JDBC driver into Tomcat's lib/ directory is pretty simple and doesn't require any other specific configuration at all. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8N83YACgkQHPApP6U8 pFhbyQ//VLHoBzkKj5FT5c/FA5/S9TDJasoj3+nBFsQmePi5Js8p4+APxklG8XPT 5Izhy6Vm4RUu088v3WKc5+zgwSuIsW9P+9xs6n9NIqhqoyRqsQGFDoxjb0FqjH6P wBjkYq1idYaVqY+DbReYRmRFIi26Is5viTVLtkDw+yTjZhgJ/GjmX2acNu05/btn 2UddYioTIsUwxhzU8mra+sMxX5LEPgpfAhAXSS21uh90xBqT5+GQQO0pfsgOHUd+ ADlQxTeYilqoOgmGQjFfAH1EqAVzc77MMAVFWvfAPp1sUv5xE5SmDdCIuESm0a8S +GITRzDcxUtFdVpo0ThEzPZVbbCoWIwhuQt9DZgsYNLgxpJMbNPknNYWo+7DkB4t rl4i3l58gpdYsRl0QBjgyIxeRK/itktLBf51L65eWHtZb1N5YQuKuRzEuzfVxEsW QonmRGi4O0FWHnQr1Zu0TKdy3bTWBqUpXua5Fg3w0D0tv5hToJ/WeGTOa/2J9Brz GwuZJW/3hpr34COedQM5bvtfEfov86EKvJotDi9O/veVrx2IgTLPasCllr3cOO2T Tmx/5IzgzAfjdDyJN4d5bDasqst4mp6fNszKVMuWuiiislSbMRpceoFR3U1zFYmC C2lez9wGwfd+H2njcDd4xJxbWjawvRzRWPGAzEmsZYB2kQIFuv0= =GdOs -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
[SECURITY] CVE-2020-13935 Apache Tomcat WebSocket Denial of Service
CVE-2020-13935 Apache Tomcat WebSocket Denial of Service Severity: Important Vendor: The Apache Software Foundation Versions Affected: Apache Tomcat 10.0.0-M1 to 10.0.0-M6 Apache Tomcat 9.0.0.M1 to 9.0.36 Apache Tomcat 8.5.0 to 8.5.56 Apache Tomcat 7.0.27 to 7.0.104 Description: The payload length in a WebSocket frame was not correctly validated. Invalid payload lengths could trigger an infinite loop. Multiple requests with invalid payload lengths could lead to a denial of service. Mitigation: - Upgrade to Apache Tomcat 10.0.0-M7 or later - Upgrade to Apache Tomcat 9.0.37 or later - Upgrade to Apache Tomcat 8.5.57 or later Credit: This issue was reported publicly via the Apache Tomcat Users mailing list without reference to the potential for DoS. The DoS risks were identified by the Apache Tomcat Security Team. References: [1] http://tomcat.apache.org/security-10.html [2] http://tomcat.apache.org/security-9.html [3] http://tomcat.apache.org/security-8.html - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
[SECURITY] CVE-2020-13934 Apache Tomcat HTTP/2 Denial of Service
CVE-2020-13934 Apache Tomcat HTTP/2 Denial of Service Severity: Moderate Vendor: The Apache Software Foundation Versions Affected: Apache Tomcat 10.0.0-M1 to 10.0.0-M6 Apache Tomcat 9.0.0.M5 to 9.0.36 Apache Tomcat 8.5.1 to 8.5.56 Description: An h2c direct connection did not release the HTTP/1.1 processor after the upgrade to HTTP/2. If a sufficient number of such requests were made, an OutOfMemoryException could occur leading to a denial of service. Mitigation: - Upgrade to Apache Tomcat 10.0.0-M7 or later - Upgrade to Apache Tomcat 9.0.37 or later - Upgrade to Apache Tomcat 8.5.57 or later Credit: This issue was reported publicly via the Apache Tomcat Users mailing list without reference to the potential for DoS. The DoS risks were identified by the Apache Tomcat Security Team. References: [1] http://tomcat.apache.org/security-10.html [2] http://tomcat.apache.org/security-9.html [3] http://tomcat.apache.org/security-8.html - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: file ownership of webapps and below
On 14.07.20 11:12, Christoph Kukulies wrote: > I found there are some mismatches in file ownership from manual installation > and moving around webapps trees from different tomcat versions. > My current tomcat (9) runs under user.group tomcat.tomcat. A couple of files > have ownership > > root.tomcat > tomcat8. > > Would it be ok to chown all files below and including webapps to > tomcat.tomcat? It depends (TM) There are those who can't operate without tomcat having write access to its own operations, e.g. because they rely on the manager app for deployments. And there are those who prefer Tomcat to not have any write access to its own applications, as a means of hardening the installation. My preference is to limit write permissions (and ownership) to temp, work and logs. Your mileage may vary. Olaf - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
file ownership of webapps and below
I found there are some mismatches in file ownership from manual installation and moving around webapps trees from different tomcat versions. My current tomcat (9) runs under user.group tomcat.tomcat. A couple of files have ownership root.tomcat tomcat8. Would it be ok to chown all files below and including webapps to tomcat.tomcat? — Christoph smime.p7s Description: S/MIME cryptographic signature
