RE: Understanding ResorceLink property inheritance
That solved the problem. I thought that I had ran into a problem where tomcat
couldn't find the classorg.apache.naming.factory.DataSourceLinkFactory before
but it must have been something else.
De: Mark Thomas
Enviado: quinta-feira, 29 de agosto de 2024 13:48
Para: users@tomcat.apache.org
Assunto: Re: Understanding ResorceLink property inheritance
On 29/08/2024 15:52, Marcelo de Sena Lacerda wrote:
> The resource definition in server.xml
>
> ...
>
> ...
> global="jdbc/mydatabase"
> auth="Container"
> type="javax.sql.DataSource"
> removeAbandoned="true"
> removeAbandonedTimeout="120"
> maxActive="5"
> maxIdle="5"
> initialSize="0"
> minIdle="0"
> maxWait="200"
> timeBetweenEvictionRunsMillis="3"
> minEvictableIdleTimeMillis="6"
> maxAge="12"
> validatorClassName="..."
> testOnBorrow="true"
> validationInterval="0"
> fairQueue="false"
> factory="org.apache.tomcat.jdbc.pool.DataSourceFactory"
> alternateUsernameAllowed="true"
> username="..." password="..."
> driverClassName="..."
> url="..."/>
OK. The global resource looks good.
> ...
>
>
>*
> Wrong factory.
>*
> driverClassName is not a valid attribute for a ResourceLink
>*
> url is not a valid attribute for a ResourceLink
>
> From reading the documentation that was also my initial thought, however if
> I write my ResourceLink like this:
>
>
> name="jdbc/mydatabase"
> global="jdbc/mydatabase"
> type="javax.sql.DataSource"
> factory="org.apache.tomcat.jdbc.pool.DataSourceFactory"
> username="..."
> password="..."
>
> />
The factory should be org.apache.naming.factory.DataSourceLinkFactory in
the ResoucreLink. Otherwise the above looks OK to me.
(Note: I'm basing this off reading the documentation - I haven't tested
that it actually works).
Mark
>
> I get the following error:
>
> javax.naming.NamingException: Unexpected exception resolving reference [Root
> exception is java.sql.SQLException: The url cannot be null
>
> When my code tries to obtain the DataSource from the context:
>
> DataSource ds = (DataSource)envContext.lookup("jdbc/mydatabase");
>
> De: Mark Thomas
> Enviado: quinta-feira, 29 de agosto de 2024 10:30
> Para: users@tomcat.apache.org
> Assunto: Re: Understanding ResorceLink property inheritance
>
> On 29/08/2024 14:19, Marcelo de Sena Lacerda wrote:
>> Understanding ResorceLink property inheritance
>>
>> My scenario is this, I have several applications running on a tomcat, all of
>> them access the same database I want them to be inside the same pool so the
>> number of connections oppened can be sensibly managed using the same
>> parameters. All of that works as of now.
>>
>> Additionally I also want them to connect to the database using different
>> users so that's easier to identify which application is running which
>> processes in the database.
>>
>> My understanding is that I could do that with setting a Resource in my
>> server.xml with all the pool configuration parameters set and a ResourceLink
>> in the context.xml of the application with only the username and password
>> set.
>
> Yes, but only under specific circumstances.
>
> https://tomcat.apache.org/tomcat-11.0-doc/config/context.html#Resource_Links
>
>> That more or less works. Indeed if setup the scenario described in the above
>> paragraph I can set a different username and password for the Resource in
>> the ResourceLink, however it seems that tomcat "forgets" every other
>> parameter of the Resource driverClass,url, and, more importantly maxActive,
>> maxIdle, initialSize all gets "forgotten" by tomcat.
>>
>> Why is that happening?
>
> We need to see the resource definition in server.xml as there may be
> changes required there as well.
>
>> I'm using tomcat 10.1.28 with java 22.0.2 from openjdk.
>>
>> This is the ResourceLink that inherits all parameters from server.xml:
>>
>> > name="jdbc/mydatabase"
>> global="jdbc/mydatabase"
>> type="javax.sql.DataSource"
>> />
>>
>> And this is one that forgets all parent parameters:
>>
>> > name="jdbc/mydatabase"
>> global="jdbc/mydatabase"
>> type="javax.sql.DataSource"
>> driverClassName="..."
>> url="..."
>> username="..."
>> password="..."
>> factory="org.apache.tomcat.jdbc.pool.DataSourceFactory"
>> />
>
> Wrong factory.
> driverClassName is not a valid attribute for a ResourceLink
> url is not a valid attribute for a ResourceLink
>
> Mark
>
>
> -
Apache Tomcat Upgrade to address Curl and libcurl vulnerabilities
Apache Tomcat Security Team: Please advise when an update to Apache Tomcat will be released that addresses the following Curl and libcurl security vulnerabilities: Critical: CVE-2023-38545 High: CVE-2024-7264 Medium: CVE-2023-46218 CVE-2023-46219 CVE-2024-0853 Low: CVE-2023-38546 Thank you, John P. Kenan DevSecOps Engineer US Environmental Protection Agency
Re: Apache Tomcat Upgrade to address Curl and libcurl vulnerabilities
John, On 8/30/24 10:15, Kenan, John wrote: Please advise when an update to Apache Tomcat will be released that addresses the following Curl and libcurl security vulnerabilities: Critical: CVE-2023-38545 High: CVE-2024-7264 Medium: CVE-2023-46218 CVE-2023-46219 CVE-2024-0853 Low: CVE-2023-38546 Apache Tomcat doesn't use curl or libcurl. Is there something specific you'd like to be addressed? -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Apache Tomcat Upgrade to address Curl and libcurl vulnerabilities
On 30/08/2024 15:15, Kenan, John wrote: Apache Tomcat Security Team: Please advise when an update to Apache Tomcat will be released that addresses the following Curl and libcurl security vulnerabilities: What makes you think Tomcat has a dependency on Curl and/or libcurl? Mark Critical: CVE-2023-38545 High: CVE-2024-7264 Medium: CVE-2023-46218 CVE-2023-46219 CVE-2024-0853 Low: CVE-2023-38546 Thank you, John P. Kenan DevSecOps Engineer US Environmental Protection Agency - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Apache Tomcat Upgrade to address Curl and libcurl vulnerabilities
Am 30. August 2024 16:20:24 MESZ schrieb Mark Thomas : >On 30/08/2024 15:15, Kenan, John wrote: >> Apache Tomcat Security Team: Hi, >> Please advise when an update to Apache Tomcat will be released that >> addresses the following Curl and libcurl security vulnerabilities: > >What makes you think Tomcat has a dependency on Curl and/or libcurl? This kind of checkbox security is also implemented at my employer. I assume a similar procedure is implemented here, and probably does involve a static code scanner of docker images and probably somehow disallows the deploy of images containing "critical" and/or "high" CVE finding... @John: what docker image are you talking about? As far as I know Apache Foundation doesn't offer an official docker image. > >Mark > > >> >> Critical: >> CVE-2023-38545 >> >> High: >> CVE-2024-7264 >> >> Medium: >> CVE-2023-46218 >> CVE-2023-46219 >> CVE-2024-0853 >> >> Low: >> CVE-2023-38546 >> >> Thank you, >> >> John P. Kenan >> DevSecOps Engineer >> US Environmental Protection Agency >> > >- >To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >For additional commands, e-mail: users-h...@tomcat.apache.org > -- Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat takes over 1 minute to stop
Thank you Mr. Shultz !!! We've had warnings like the below forever. I can confirm that these have not affected stopping in anyway whatsoever. WARNING [Catalina-utility-11] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [web app name] appears to have started a thread named [thread name] but has failed to stop it. This is very likely to create a memory leak.. We did try to fix this in the form of a context listener servlet to clean up these threads during destroying the context process but, again, this has had no effects whatsoever. === Tomcat9w.exe --> Shutdown tab --> Timeout >From the logs that I sent, I believe that: Apache Commons Daemon procrun (1.3.4.0 64-bit) --> took this Timeout into account Apache Commons Daemon procrun (1.4.0.0 64-bit) --> did NOT take this Timeout into account From: Christopher Schultz Sent: Thursday, August 29, 2024 5:59 PM To: users@tomcat.apache.org Subject: Re: Tomcat takes over 1 minute to stop Quoc, On 8/29/24 15:23, Quoc Nguyen wrote: > Thank you Mr. Thomas !!! > > Yes sir !!! I noticed that a clean Tomcat 9.0.93 install (as with other > 9.0.9x versions) stops around 1s. I believe that it is so because it has no > managed web apps/resources. Just Tomcat itself. I could be wrong. > > Yes, I noticed that there are warnings of non-daemon threads that weren't > stopped in catalina.log. I read somewhere that they're just warnings; thus > don't affect this process. > > There are no requests running at all while stopping Tomcat. Essentially, > install/deploy different versions (9.0.89, 9.0.9x) of Tomcat with the same > set of non-changing web apps and stop Tomcat via Windows service and record > the stop times. > > Yes, I took the thread dumps while stopping version 9.0.90. There is a thread > "DestroyJavaVM" that, after a few seconds after Tomcat receives the shutdown > signal (maybe after it's done stopping its main stuff), was running for 60s. > > That said, there're no explanations for what happened: > > a) between version 9.0.13 and 9.0.14 with the introduction of "..scheduled > executor to the Server..", which has default wait time of 60s and forces a > Timeout in Tomcat9w.exe to get Tomcat stop under 60s. > b) between version 9.0.89 and 9.0.90 after the upgrade of Apache Commons > Daemon procrun to version 1.4.0.0, which has a default pause of 60s. > > More work/data to confirm: I'm working with Tomcat version 9.0.89 and 9.0.90 > (where I noticed the change) in two different boxes. > > For version 9.0.90 box: started and stopped. Daemon logs below. > > Note: > > * Apache Commons Daemon procrun (1.4.0.0 64-bit) > * exactly 60s wait until finished regardless of the Timeout set in > Tomcat9w.exe > > [2024-08-29 13:41:58] [info] [13472] Apache Commons Daemon procrun (1.4.0.0 > 64-bit) started. > [2024-08-29 13:41:58] [info] [13472] Running Service 'Tomcat9'... > [2024-08-29 13:41:58] [info] [ 9148] Starting service... > [2024-08-29 13:41:58] [error] [12380] Could not create instance of > java/io/FileOutputStream > [2024-08-29 13:41:59] [info] [ 9148] Service started in 1636 milliseconds. > [2024-08-29 13:42:40] [info] [13472] Service SERVICE_CONTROL_STOP signalled. > [2024-08-29 13:42:40] [info] [11996] Stopping service... > [2024-08-29 13:43:06] [info] [11996] Service stop thread completed. > [2024-08-29 13:44:06] [info] [13472] Run service finished. > [2024-08-29 13:44:06] [info] [13472] Apache Commons Daemon procrun finished. > > > For version 9.0.90 box: switched version 9.0.89 of Tomcat9.exe into this box. > Started and stopped. Daemon logs below. > > Note: > > * Apache Commons Daemon procrun (1.3.4.0 64-bit) > * stop time is definitely less than 60s if the Timeout set in Tomcat9w.exe is > less than 60 and ~63s (or 1 min 3 secs as reported) when set to 0 (out of > the box) > * the last two log lines of "out of the box" don't appear in the log for > Timeout being set to 5. Speculation: the process is short-circuited taking > into account the set Timeout. > > The Timeout was set for 5: > > [2024-08-29 14:08:04] [info] [11012] Apache Commons Daemon procrun (1.3.4.0 > 64-bit) started. > [2024-08-29 14:08:04] [info] [11012] Running Service 'Tomcat9'... > [2024-08-29 14:08:04] [info] [14356] Starting service... > [2024-08-29 14:08:05] [error] [ 6740] Could not create instance of > java/io/FileOutputStream > [2024-08-29 14:08:06] [info] [14356] Service started in 1648 milliseconds. > [2024-08-29 14:08:47] [info] [11012] Service SERVICE_CONTROL_STOP signalled. > [2024-08-29 14:08:47] [info] [14432] Stopping service... > [2024-08-29 14:08:58] [info] [14432] Service stop thread completed. > > > The Timeout was set for 0 (out of the box): > > [2024-08-29 14:43:51] [info] [ 8848] Apache Commons Daemon procrun (1.3.4.0 > 64-bit) started. > [2024-08-29 14:43:51] [info] [ 8848] Running Service 'Tomcat9'... > [2024-08-29
Re: Tomcat 10.1 Http11NioProtocol with the OpenSSLImplementation does not sent close_notify in response to client's close_notify
On 29/08/2024 14:05, Christopher Schultz wrote: Isaac, On 8/26/24 13:24, Isaac Klickstein wrote: What is the "Tomcat Native Client"? I am using the Tomcat Native software (maybe "client" was wrong) available here to build the OpenSSLImplementation: https://tomcat.apache.org/download-native.cgi#2.0.8 I then link to this library using LD_LIBRARY_PATH in the Tomcat's setenv.sh script. Aah, okay. You are just using libtcnative on the server side. curl is the client. How do you trigger this behavior? Just any request like "curl I have been using the manager app, something like curl --cacert --url 'https://:https connector port>/manager/text/list' --user robot:robotpw but any request to the ROOT/manager/other hosted would do. I have been breaking down the behavior based on protocol=NIO/NIO2/APR and the sslImplementationName JSSE/OpenSSL NIO/NIO2+JSSE = good NIO/NIO2+OpenSSL = bad APR+OpenSSL = good That's interesting. When using APR+OpenSSL, the Tomcat code is entirely responsible for the connection management (e.g. socket, buffers, etc.) and the crypto (using OpenSSL, of course). When using NIO+OpenSSL, Java is responsible for the connection management AND the orchestration of the use of the cryptographic module. The use of OpenSSL versus some other cryptographic module (e.g. built-in JSSE) should not affect whether a close_notify is sent. :/ I have TCP dumps for each of these configurations saved and could upload them as well as the configuration of the connectors. Is a TCP dump required to observe this behavior, or will e.g. curl -vvv show it as well? Is this causing any actual issues in your environment, or are you more reporting a spec violation that needs to be cleaned-up. It seems to be that if the client asks the server to close the connection, if the connection is closed then it's closed whether or not this particular message is transmitted before termination of the connection. This should be fixed for the next round of releases. Mark -chris On Monday, August 26th, 2024 at 11:40 AM, Christopher Schultz wrote: Isaac, On 8/25/24 13:27, Isaac Klickstein wrote: Hello Tomcat Users Tomcat Version: 10.1.28 OpenSSL version: 3.0.14 Tomcat Native Client: 2.0.8 What is the "Tomcat Native Client"? I have configured an HTTPS connector with the org.apache.coyote.http11.Http11NioProtocol protocol and the org.apache.tomcat.util.net.openssl.OpenSSLImplementation sslImplementationName using TLSv1.2 When I tcpdump any request to this connector, Tomcat is not returning a "close_notify" in response to a client's close_notify, and I cannot figure out how to force Tomcat to return a close_notify. This seems to be a violation of the TLS protocol which demands both sides issue a close_notify. Careful: both the client and the server are always allowed to be powered-off before they respond to any network stimulus. This is what timeouts are for. TLS cannot place any more requirements on the network peers than TCP has already done. Recreating this situation, as far as I can tell, only requires combining the Http11NioProtocol with the OpenSSLImplementation (Tomcat9 or Tomcat10, TLSv1.2 or TLSv1.3, OpenSSL 3.0, 3.1, and 3.2, all exhibit this behavior). How do you trigger this behavior? Just any request like "curl https://example.com/"; ? Other notes, switching the sslImplementationName to org.apache.tomcat.util.net.jsse.JSSEImplementation does return a close_notify by the server in response to the client's close_notify. Also, switching back to Tomcat9, and using the org.apache.coyote.http11.Http11AprProtocol, Tomcat also returns a close_notify in response to a client's close_notify. I have run out of ideas, googling this behavior has turned up nothing related to Tomcat (although there does appear to be a similar behavior noticed in Netty also using the OpenSSLEngine https://github.com/netty/netty/issues/6167) Any help would be greatly appreciated, I am happy to send along any other information that would be informational for diagnostics So... Tomcat 10.1 + NIO/JSSE+OpenSSLImplementation+tcnative = bad Tomcat 9.0 + APR+tcnative = good Tomcat 9.0 + NIO/JSSE+OpenSSLImplementation+tcnative = ? -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail:
