[Bug 64488] New: EL API: AccessControlException -- Import Handler
https://bz.apache.org/bugzilla/show_bug.cgi?id=64488
Bug ID: 64488
Summary: EL API: AccessControlException -- Import Handler
Product: Tomcat 10
Version: 10.0.0-M5
Hardware: Macintosh
OS: Mac OS X 10.1
Status: NEW
Severity: normal
Priority: P2
Component: EL
Assignee: dev@tomcat.apache.org
Reporter: volosied+apa...@gmail.com
Target Milestone: --
Created attachment 37286
--> https://bz.apache.org/bugzilla/attachment.cgi?id=37286=edit
Patch
Hello,
I encountered an AccessControlException when using the Tomcat 10.0.0-M5 EL API
in Open Liberty.
The stack trace is provided below, but the exception is thrown starting on this
line: jakarta.el.ImportHandler.findClass(ImportHandler.java:455)
I would appreciate if someone look whether a security check should be added in
the code. It appears to be a valid scenario. I've added a patch for reference
(based off code from ExpressionFactory.java).
We also used the same Tomcat 10.0.0-M5 Jasper EL Implementation.
The application was run on the following JDK:
openjdk version "1.8.0_222"
OpenJDK Runtime Environment (build 1.8.0_222-b10)
Eclipse OpenJ9 VM (build openj9-0.15.1, JRE 1.8.0 Mac OS X amd64-64-Bit
Compressed References 20190717_298 (JIT enabled, AOT enabled)
OpenJ9 - 0f66c6431
OMR - ec782f26
JCL - f147086df1 based on jdk8u222-b10)
Please let me know if you have any questions. Thank you.
_
Permission:
("java.io.FilePermission"
"/Library/Java/JavaVirtualMachines/adoptopenjdk-8-openj9.jdk/Contents/Home/jre/lib/rt.jar"
"read")
Stack:
java.security.AccessControlException: Access denied ("java.io.FilePermission"
"/Library/Java/JavaVirtualMachines/adoptopenjdk-8-openj9.jdk/Contents/Home/jre/lib/rt.jar"
"read")java.security.AccessController.throwACE(AccessController.java:176)
java.security.AccessController.checkPermissionHelper(AccessController.java:238)
java.security.AccessController.checkPermission(AccessController.java:385)
java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
com.ibm.ws.kernel.launch.internal.MissingDoPrivDetectionSecurityManager.checkPermission(MissingDoPrivDetectionSecurityManager.java:45)
com.ibm.oti.vm.AbstractClassLoader.findResource(AbstractClassLoader.java:194)
java.lang.ClassLoader.getResource(ClassLoader.java:584)
java.lang.ClassLoader.getResource(ClassLoader.java:586)
java.lang.ClassLoader.getResource(ClassLoader.java:586)
com.ibm.ws.kernel.internal.classloader.BootstrapChildFirstJarClassloader.getResource(BootstrapChildFirstJarClassloader.java:110)
org.eclipse.osgi.internal.loader.BundleLoader.findResource(BundleLoader.java:621)
org.eclipse.osgi.internal.loader.ModuleClassLoader.getResource(ModuleClassLoader.java:216)
com.ibm.ws.classloading.internal.GatewayClassLoader.findResource(GatewayClassLoader.java:134)
com.ibm.ws.classloading.internal.GatewayClassLoader.getResource(GatewayClassLoader.java:116)
java.lang.ClassLoader.getResource(ClassLoader.java:586)
jakarta.el.ImportHandler.findClass(ImportHandler.java:455)
jakarta.el.ImportHandler.resolveClass(ImportHandler.java:417)
jakarta.servlet.jsp.el.ScopedAttributeELResolver.getValue(ScopedAttributeELResolver.java:93)
org.apache.jasper.el.JasperELResolver.getValue(JasperELResolver.java:110)
org.apache.el.parser.AstIdentifier.getValue(AstIdentifier.java:94)
org.apache.el.parser.AstValue.getValue(AstValue.java:137)
org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:190)
org.apache.jasper.runtime.PageContextImpl.proprietaryEvaluate(PageContextImpl.java:794)
com.ibm._jsp._EL30StaticFieldsAndMethodsTests._jspService(_EL30StaticFieldsAndMethodsTests.java:109)
com.ibm.ws.jsp.runtime.HttpJspBase.service(HttpJspBase.java:100)
--
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 57129] Regression. Load WEB-INF/lib jarfiles in alphabetical order
https://bz.apache.org/bugzilla/show_bug.cgi?id=57129 --- Comment #29 from Christopher Schultz --- (In reply to Mateusz Matela from comment #28) > (In reply to Mark Thomas from comment #27) > > The patch would have to be very minimal and the behaviour > > optional to be considered for inclusion in Tomcat. > > Can you explain why this has to be optional? Because it's very nearly a spec violation. Assuming that users never switch application servers, it's probably harmless. But if you use a sorting-Tomcat and move to JBoss and your stuff stops working, JBoss will tell you the same thing: you were relying on some wacky behavior those crazy kids at Apache Tomcat were willing to do, and now you have to grow up and adhere to published specifications. > Is there any conceivable scenario where someone would prefer to > have non-deterministic behavior? Probably not. Why do you have JAR files that rely on specific ordering to maintain determinism? I can't understand why someone would build an application like that. Your move. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
buildbot success in on tomcat-9-trunk
The Buildbot has detected a restored build on builder tomcat-9-trunk while building tomcat. Full details are available at: https://ci.apache.org/builders/tomcat-9-trunk/builds/260 Buildbot URL: https://ci.apache.org/ Buildslave for this Build: asf946_ubuntu Build Reason: The AnyBranchScheduler scheduler named 'on-tomcat-9-commit' triggered this build Build Source Stamp: [branch 9.0.x] 575a2b3f3b23474305f3d6333cedda75d600b629 Blamelist: remm Build succeeded! Sincerely, -The Buildbot - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
buildbot success in on tomcat-trunk
The Buildbot has detected a restored build on builder tomcat-trunk while building tomcat. Full details are available at: https://ci.apache.org/builders/tomcat-trunk/builds/5211 Buildbot URL: https://ci.apache.org/ Buildslave for this Build: asf946_ubuntu Build Reason: The AnyBranchScheduler scheduler named 'on-tomcat-commit' triggered this build Build Source Stamp: [branch master] be5025de4d21cb5e0e7e4573e22c6b8a79e01443 Blamelist: remm Build succeeded! Sincerely, -The Buildbot - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 64485] UserDatabase Realm leaks os file descriptors for conf/tomcat-users.xml
https://bz.apache.org/bugzilla/show_bug.cgi?id=64485 Remy Maucherat changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Remy Maucherat --- The fis will be in 10.0.0-M6 and 9.0.36. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] branch 9.0.x updated: 64485: Fix possible resource leak
This is an automated email from the ASF dual-hosted git repository.
remm pushed a commit to branch 9.0.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/9.0.x by this push:
new 575a2b3 64485: Fix possible resource leak
575a2b3 is described below
commit 575a2b3f3b23474305f3d6333cedda75d600b629
Author: remm
AuthorDate: Mon Jun 1 15:58:02 2020 +0200
64485: Fix possible resource leak
And actually use ConfigurationSource.Resource.getLastModified.
---
java/org/apache/catalina/users/MemoryUserDatabase.java| 2 +-
java/org/apache/tomcat/util/file/ConfigurationSource.java | 11 ++-
webapps/docs/changelog.xml| 4
3 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/java/org/apache/catalina/users/MemoryUserDatabase.java
b/java/org/apache/catalina/users/MemoryUserDatabase.java
index 6062c75..a9d3fc8 100644
--- a/java/org/apache/catalina/users/MemoryUserDatabase.java
+++ b/java/org/apache/catalina/users/MemoryUserDatabase.java
@@ -425,7 +425,7 @@ public class MemoryUserDatabase implements UserDatabase {
String pathName = getPathname();
try (ConfigurationSource.Resource resource =
ConfigFileLoader.getSource().getResource(pathName)) {
-this.lastModified =
resource.getURI().toURL().openConnection().getLastModified();
+lastModified = resource.getLastModified();
// Construct a digester to read the XML input file
Digester digester = new Digester();
diff --git a/java/org/apache/tomcat/util/file/ConfigurationSource.java
b/java/org/apache/tomcat/util/file/ConfigurationSource.java
index 2df11bc..57d5ce4 100644
--- a/java/org/apache/tomcat/util/file/ConfigurationSource.java
+++ b/java/org/apache/tomcat/util/file/ConfigurationSource.java
@@ -24,6 +24,7 @@ import java.io.InputStream;
import java.net.MalformedURLException;
import java.net.URI;
import java.net.URL;
+import java.net.URLConnection;
/**
* Abstracts configuration file storage. Allows Tomcat embedding using the
regular
@@ -92,7 +93,15 @@ public interface ConfigurationSource {
}
public long getLastModified()
throws MalformedURLException, IOException {
-return uri.toURL().openConnection().getLastModified();
+URLConnection connection = null;
+try {
+connection = uri.toURL().openConnection();
+return connection.getLastModified();
+} finally {
+if (connection != null) {
+connection.getInputStream().close();
+}
+}
}
@Override
public void close() throws IOException {
diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index a5e3266..dc7b498 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -91,6 +91,10 @@
Expose server certificate through the SSLSupport
interface. (remm)
+
+64485: Fix possible resource leak geting last modified from
+ConfigurationSource.Resource. (remm)
+
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] branch master updated: 64485: Fix possible resource leak
This is an automated email from the ASF dual-hosted git repository.
remm pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/master by this push:
new be5025d 64485: Fix possible resource leak
be5025d is described below
commit be5025de4d21cb5e0e7e4573e22c6b8a79e01443
Author: remm
AuthorDate: Mon Jun 1 15:58:02 2020 +0200
64485: Fix possible resource leak
And actually use ConfigurationSource.Resource.getLastModified.
---
java/org/apache/catalina/users/MemoryUserDatabase.java| 2 +-
java/org/apache/tomcat/util/file/ConfigurationSource.java | 11 ++-
webapps/docs/changelog.xml| 4
3 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/java/org/apache/catalina/users/MemoryUserDatabase.java
b/java/org/apache/catalina/users/MemoryUserDatabase.java
index 6062c75..a9d3fc8 100644
--- a/java/org/apache/catalina/users/MemoryUserDatabase.java
+++ b/java/org/apache/catalina/users/MemoryUserDatabase.java
@@ -425,7 +425,7 @@ public class MemoryUserDatabase implements UserDatabase {
String pathName = getPathname();
try (ConfigurationSource.Resource resource =
ConfigFileLoader.getSource().getResource(pathName)) {
-this.lastModified =
resource.getURI().toURL().openConnection().getLastModified();
+lastModified = resource.getLastModified();
// Construct a digester to read the XML input file
Digester digester = new Digester();
diff --git a/java/org/apache/tomcat/util/file/ConfigurationSource.java
b/java/org/apache/tomcat/util/file/ConfigurationSource.java
index 2df11bc..57d5ce4 100644
--- a/java/org/apache/tomcat/util/file/ConfigurationSource.java
+++ b/java/org/apache/tomcat/util/file/ConfigurationSource.java
@@ -24,6 +24,7 @@ import java.io.InputStream;
import java.net.MalformedURLException;
import java.net.URI;
import java.net.URL;
+import java.net.URLConnection;
/**
* Abstracts configuration file storage. Allows Tomcat embedding using the
regular
@@ -92,7 +93,15 @@ public interface ConfigurationSource {
}
public long getLastModified()
throws MalformedURLException, IOException {
-return uri.toURL().openConnection().getLastModified();
+URLConnection connection = null;
+try {
+connection = uri.toURL().openConnection();
+return connection.getLastModified();
+} finally {
+if (connection != null) {
+connection.getInputStream().close();
+}
+}
}
@Override
public void close() throws IOException {
diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index eb3c72d..056cf3b 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -87,6 +87,10 @@
Expose server certificate through the SSLSupport
interface. (remm)
+
+64485: Fix possible resource leak geting last modified from
+ConfigurationSource.Resource. (remm)
+
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 64485] UserDatabase Realm leaks os file descriptors for conf/tomcat-users.xml
https://bz.apache.org/bugzilla/show_bug.cgi?id=64485 --- Comment #1 from Remy Maucherat --- I guess it can be improved, but this problem actually doesn't do anything for me, so I never care. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 57129] Regression. Load WEB-INF/lib jarfiles in alphabetical order
https://bz.apache.org/bugzilla/show_bug.cgi?id=57129 --- Comment #28 from Mateusz Matela --- (In reply to Mark Thomas from comment #27) > The patch would have to be very minimal and the behaviour > optional to be considered for inclusion in Tomcat. Can you explain why this has to be optional? Is there any conceivable scenario where someone would prefer to have non-deterministic behavior? -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 64486] Receiving null/empty request body when SSL enabled
https://bz.apache.org/bugzilla/show_bug.cgi?id=64486 mgrigorov changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #1 from mgrigorov --- There is no proof is a bug in the description. Please use us...@tomcat.apache.org for support! -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 64486] New: Receiving null/empty request body when SSL enabled
https://bz.apache.org/bugzilla/show_bug.cgi?id=64486
Bug ID: 64486
Summary: Receiving null/empty request body when SSL enabled
Product: Tomcat 9
Version: 9.0.31
Hardware: HP
OS: Linux
Status: NEW
Severity: major
Priority: P2
Component: Connectors
Assignee: dev@tomcat.apache.org
Reporter: vink...@gmail.com
Target Milestone: -
I am posting large body(~12-18kb) to the REST . The endpoint is receiving
null/empty Request Body randomly(not with every request).
When I am facing this issue:
1. When SSL(self-signed) is enabled in
spring-boot(https://server:port/{endpoint})
2. The issue is not consistent , it happens randomly(not every request)
3. Issue does not occur when the post body size is very low.
4. Same request works for HTTP consistently but not with HTTPS
Project Details:
1. Spring Boot 2.2.5 with Tomcat as embedded server
2. TLSV12
3. OpenJDK8
4. Certificate is Selfsigned
What we have tried to debug
1. Decrypted tcpdump shows the body is present.
2. Tried changing the JVM, spring boot server configuration
(heapsize,stacksize, ciphers change )
3. Checked the logs, have not found anything concrete.
--
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 64485] UserDatabase Realm leaks os file descriptors for conf/tomcat-users.xml
https://bz.apache.org/bugzilla/show_bug.cgi?id=64485 Vassili Alibabaev changed: What|Removed |Added Attachment #37285|Stacktrace of file open |Stacktrace of file open description|failure when os file|failure when os file |descriptors is over |descriptors are over |(recorded with v9.0.29) |(recorded with v9.0.29) -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 64485] New: UserDatabase Realm leaks os file descriptors for conf/tomcat-users.xml
https://bz.apache.org/bugzilla/show_bug.cgi?id=64485 Bug ID: 64485 Summary: UserDatabase Realm leaks os file descriptors for conf/tomcat-users.xml Product: Tomcat 9 Version: 9.0.35 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P2 Component: Catalina Assignee: dev@tomcat.apache.org Reporter: angry.sk...@yandex.ru Target Milestone: - Created attachment 37285 --> https://bz.apache.org/bugzilla/attachment.cgi?id=37285=edit Stacktrace of file open failure when os file descriptors is over (recorded with v9.0.29) There is a bug in org.apache.catalina.users.MemoryUserDatabase that leaves the os file descriptors in open state. This is caused by the code line: https://github.com/apache/tomcat/blob/9.0.35/java/org/apache/catalina/users/MemoryUserDatabase.java#L428 Exact code line is: this.lastModified = resource.getURI().toURL().openConnection().getLastModified(); The org.apache.tomcat.util.file.ConfigurationSource.Resource is handled properly by the try-with-resources block, but a call to the URI/URL inside this block does not close any opened resources. These resources just stay in memory and occupy limited os resources. There is a similar bug in the OpenJDK: https://bugs.openjdk.java.net/browse/JDK-6956385 This behavior was introduced in version 9.0.13 and after bugs: https://bz.apache.org/bugzilla/show_bug.cgi?id=62924 https://bz.apache.org/bugzilla/show_bug.cgi?id=62958 The leaked file handles are usually collected by the GC, but if server has enough memory and stays idle, then too many handles are acquired from the os and there is no more available. A stacktrace of such failure is in the attachment. The read time period is 10 seconds by default and one file handle is leaked withing every read of tomcat-users.xml file. MemoryUserDatabase#watchSource is also true by default and this behavior is enabled in the default conf. A list of open files can be obtained by cmd: lsof -K | grep $TOMCAT_PID | grep "tomcat-users.xml" | wc -l org.apache.tomcat.util.file.ConfigurationSource.Resource#getLastModified() may be voulnerable too. Please analyze all places where java.net.URL#openConnection() is used -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Tomcat Docker using AdoptOpenJDK-OpenJ9
Hi, Following on this, as I have raised a PR https://github.com/docker-library/tomcat/pull/202 to add the SCC options into the OpenJ9 Docker file to avail this improvement, I got comments saying that they would do only if upstream recommends. As all individual users may not know that this option helps, we would like to get this added into OpenJ9 Docker file itself. I wanted to check with the community, if you are OK adding it ? Or any suggestions you would like to share on this ? Thank You! ```If this is something upstream recommends, shouldn't it be noted in their documentation? Maybe a configuration file/option which tells catalina.sh to use their preferred options? It seems like even a dedicated subcommand (like run) to generate them would be useful, especially if the options during generation need to be different than the options during runtime. Given that I'm not aware of any documentation from upstream which recommends this and that this is something users can accomplish in a dependent Dockerfile that's FROM tomcat:...-openj9, I'm inclined to not do this at this level for now.``` On Thu, May 21, 2020 at 2:02 PM Martin Grigorov wrote: > > > On Mon, May 18, 2020 at 2:45 PM kusuma chalasani > wrote: > >> Hi all, >> >> I'm a Performance Analyst for JVM runtime. I recently tried out some >> experiments to compare Tomcat startup performance in Docker using >> AdoptOpenJDK-OpenJ9 >> >> I found I was able to get ~30% faster startup time with very minimal >> change in footprint when I enable SharedClass Cache when I compared to the >> default(which is No Shareclasses). I wrote a detailed blog post here >> https://blog.openj9.org/2020/05/18/startup-performance-of-tomcat-in-docker/ >> where >> I outlined what and how I measured. >> >> I also did raise a PR for the same - >> https://github.com/docker-library/tomcat/pull/202 >> >> We figured we'd reach out to you guys so you can take a look, and maybe >> try it out and let us know if you have any comments/questions. >> > > Thank you for sharing your findings with us, Kusuma! > > >> >> >> Thanks, >> Kusuma. >> > -- Thanks, Kusuma.
