I we don’t have permission to use ServiceLoader Log4j will simply fail to 
initialize with anything other than SimpleLoggerContextFactory (i.e. - nothing 
in log4j-core will work). 

It looks to me that the issue in 2.18.0 is that ServiceLoaderUtil is accessing 
ServiceLoader via a MethodHandle and that must be requiring the 
SecurityManager. We are using MethodHandlers so that it will work properly in a 
JPMS environment. One solution that I think would work for this would be to 
check if JPMS is active and if not directly call ServiceLoader.

Ralph


> On Aug 21, 2022, at 9:31 AM, . . <bu.apa...@mail.unckel.net> wrote:
> 
> Hello all,
> 
> thanks Piotr to take care for the topic. One thing to consider:
> 
>> The environment and system properties sources are protected by internal Java 
>> security checks,... 
> 
> Unfortunately not after applying the fix: PropertiesUtil[1] loads all the 
> services which provide a PropertySource inside the doPrivileged including the 
> default log4j2 implementations[2] which include the system properties [3]. 
> Both fix approaches are not good at the moment. In practice nearly all 
> frameworks require Property* permissions, due to caching / loading all etc. 
> But that is not a good reason to introduce a leak. Maybe a alternative with 
> more refactoring: Only the really needed properties are loaded, without a 
> util method, without a service in between. The SecurityExceptions are thrown 
> and not silently ignored. Any service implementation has to care itself.
> 
> I don't know enough about service loading: Would any service lookup inside a 
> doPrivileged block cause a constructor to be called inside the same block? :-(
> 
> One thing in general: Could someone explain the usecase behind catching 
> SecurityExceptions and silently dropping them? [4][5][6][7][8] Please explain 
> it for the case that an authorized administrator with the knowledge and right 
> to grant permissions wants to set the permissions correct. Please explain it 
> for an monitoring system (ELK or something) which is configured to alert for 
> SecurityExceptions.
> 
> The hope of a near end of the SecurityManager must be delayed till December 
> 2030[9] as long as you want to support Java 8 with log4j2 ;-) Due to very 
> positive experience in application testing and production I'm not happy about 
> the deprecation, but that is offtopic.
> 
> Regards
> Boris
> 
> [1] 
> https://github.com/apache/logging-log4j2/blob/b734a4f66af868f03dafafe5de92999058096eca/log4j-api/src/main/java/org/apache/logging/log4j/util/PropertiesUtil.java#L477
> [2] 
> https://github.com/apache/logging-log4j2/blob/release-2.x/log4j-api/src/main/resources/META-INF/services/org.apache.logging.log4j.util.PropertySource
> [3] 
> https://github.com/apache/logging-log4j2/blob/release-2.x/log4j-api/src/main/java/org/apache/logging/log4j/util/SystemPropertiesPropertySource.java#L44
> [4] 
> https://github.com/apache/logging-log4j2/blob/release-2.x/log4j-api/src/main/java/org/apache/logging/log4j/util/SystemPropertiesPropertySource.java#L45
> [5] 
> https://github.com/apache/logging-log4j2/blob/release-2.x/log4j-api/src/main/java/org/apache/logging/log4j/util/SystemPropertiesPropertySource.java#L76
> [6] 
> https://github.com/apache/logging-log4j2/blob/release-2.x/log4j-api/src/main/java/org/apache/logging/log4j/util/SystemPropertiesPropertySource.java#L85
> [7] 
> https://github.com/apache/logging-log4j2/blob/release-2.x/log4j-api/src/main/java/org/apache/logging/log4j/util/PropertiesUtil.java#L405
> [8] 
> https://github.com/apache/logging-log4j2/blob/release-2.x/log4j-api/src/main/java/org/apache/logging/log4j/util/PropertiesUtil.java#L456
> [9] https://www.oracle.com/java/technologies/java-se-support-roadmap.html

Reply via email to