j.m.u.FactoryFinder.factoryFromServiceLoader needs PrivilegedAction

[boris-unckel]

Describe the bug
Using the service load approach jakarta.mail.util.FactoryFinder.factoryFromServiceLoader with an active security fails in an AppServer environment. The user space app would be forced to grant the permission. This is what we got in WildFly 27:

Here is the stack trace https://gist.github.com/jamezp/0c413ca12a51c5f39843702cdd003ddb

This is where the issue would be https://github.com/eclipse-ee4j/mail/blob/c424303d5dafab2921c3893085a6662f69550ef5/api/src/main/java/jakarta/mail/util/StreamProvider.java#L176-L178. Specifically this https://github.com/eclipse-ee4j/mail/blob/c424303d5dafab2921c3893085a6662f69550ef5/api/src/main/java/jakarta/mail/util/FactoryFinder.java#L130. That would need to be in a privileged action.

Expected behavior
Use a PrivilegedAction to load the service, sample code here: https://github.com/eclipse-ee4j/mail/blob/c424303d5dafab2921c3893085a6662f69550ef5/api/src/main/java/jakarta/mail/util/FactoryFinder.java#L90 )

Additional context
A cleaner approach could be a spec defined permission check on accessing the mail API i.e. a general permission we could apply to the deployment - then internally once that permission check has been performed use a doPrivileged to drop the callers protection domain from the specific permissions check as the caller does not need to know about the details.

Discussion about the bug started here
https://wildfly.zulipchat.com/#narrow/stream/174184-wildfly-developers/topic/Jakarta.20Mail

[scottmarlow]

If someone creates a pull request that addresses this issue and the change is approved, could that change be included in a Jakarta Mail 2.1.1 service release?