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.)

-chris

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

Reply via email to