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
