Fixing semantics of running with a SecurityManager in the 2.x branch makes 
perfect sense. In 3.x, we might be able to relax that type of code as it’s 
mostly module related security boundaries we need to continue supporting.

—
Matt Sicker

> On Aug 21, 2022, at 11:32, . . <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