Mark,
On 11/8/22 12:36, Mark Thomas wrote:
On 08/11/2022 16:47, Christopher Schultz wrote:
Mark,
On 11/7/22 16:53, Mark Thomas wrote:
On 07/11/2022 21:08, Christopher Schultz wrote:
Mark,
On 11/7/22 11:24, Mark Thomas wrote:
Hi,
BZ 66294 [1] highlights the performance impact in Tomcat of some
additional SecurityManager checks that were added to avoid
AccessControlException when using the EL API JAR outside of Tomcat.
Details of the performance impact are in the bug report.
I think we have a few options here.
1. Assume Tomcat 11 will remove the SecurityManager. No nothing for
now and advise the reporter to move to Tomcat 11 when available.
2. Do nothing.
3. Disable this check by default and an option (it will have to be
a system property) to enable it.
4. Something else.
Thoughts?
I am currently leaning towards 3 given that the performance impact
is noticeable and that the check isn't required in normal usage.
I thought we only wrapped stuff in doPrivileged() when a
SecurityManager was installed. Re-re-reading the bug report, it's
clear that the reporter IS running under SM.
If the reporter is running under SM and the code does not fail,
doesn't that mean that the check isn't actually providing any
benefit? The thread must already be running in a privileged context
if making that call does not throw an exception at runtime.
Can we just remove it entirely?
Maybe I'm missing something...
When used in Tomcat that code is always called from within another
doPrivileged() call further up the stack and all the stack frames
inbetween are for Tomcat provided code so the security checks pass.
Hence you can skip this doPrivileged() if running in Tomcat.
When used outside of Tomcat (EL is completely stand-alone) that isn't
the case and you need to use doPrivileged() to avoid the exceptions.
Gotcha. And I suppose it's not really possible to detect if we are
already running as a privileged operation? (Similar to how the JVM
knows that obtaining a lock a thread already has is very quick.)
It might be. But the challenge is detecting if we are running under the
right privileged operation. What we really need is "Are we on a Tomcat
request processing thread?".
In older Tomcat versions we have ContainerThreadMarker but it is unused
and I don't really like referring to that - even via reflection - in the
API classes. There is precedence but I still don't like it.
If there is a neater way of doing this, I'm likely to be all for it as
most solutions are likely to be better (in my view) than another system
property.
ThreadLocal? Or is that too fragile?
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
