I was unable to recreate a similar error than in the ticket. We may consider adding a small jar with a fake CDI provider to be in the same condition.
I had to create another SecurityActions class for the api package: not very happy with that: suggestions are welcome

I don't think that ServiceLoader.load() requires a privileged block. See also my comment: https://issues.jboss.org/browse/CDI-727?focusedCommentId=13597453&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13597453

I had to create another SecurityActions class for the api package.

No problem. That's a common practice.

Yes, good point. I forgot that we switched to service loader from 1.2 to 2.0

I had to create another SecurityActions class for the api package.

No problem. That's a common practice.

Hmm, just genuinely interested - why is it common practice? Just to prevent anyone using it? I thought these SM calls are basically caller-sensitive. So even if it was used by someone else, it shouldn't cause harm. But I guess I am missing something here?

@manovotn If you make the SecurityActions public then anyone can use it and thus "hijack" the permissions assigned to Weld.

Hmm that's exactly what I thought would be addressed by caller sensitivity, apparently I was wrong. Thanks for explanation.

@manovotn The point is that a "privileged" caller basically removes the callers up in the stack from the set of callers that will be checked when making access control decisions. Weld's SecurityActions is a privileged caller in this case. So if SecurityActions was public and Foo invoked SecurityActions.getDeclaredMethods() then Foo does not have to have the relevant permissions -> security leak.

Whenever a resource access is attempted, all code traversed by the execution thread up to that point must have permission for that resource access, unless some code on the thread has been marked as "privileged".

See also https://docs.oracle.com/javase/7/docs/technotes/guides/security/doprivileged.html

@antoinesd I just tested this with EntityListenerBeanManagerInjectionTestCase in wildfly testsuite (with WFLY-10125 workaround removed and set to use cdi-api:2.1-SNAPSHOT) and I confirm this fixes the bug. 👍

Thanks @hkalina. Do you have a suggestion to create a simple test to reproduce your issue? Mine is obviously too basic since it doesn't trigger any AccessControlException without privileged code bloc.

@antoinesd are you sure the test is running with security manager enabled? (is System.getSecurityManager() not null?)