ppkarwasz commented on issue #4181: URL: https://github.com/apache/logging-log4j2/issues/4181#issuecomment-4958930337
Hi @h4xr, Thank you for opening this public issue. Since the scenario you describe is theoretical rather than something observed in production, I would rather hold off on adding any new settings until a concrete use case comes along. Capping the number of routes open at any given time would silently break users who have deliberately chosen to create a **huge** number of appenders and provisioned enough resources to handle that workload. The only related report we have received (#2255) came from a user allocating appenders dynamically, and against our advice they chose to write custom code instead of using `RoutingAppender`. What we can usefully do is expand the [`RoutingAppender` documentation](https://logging.apache.org/log4j/2.x/manual/appenders/delegating.html#RoutingAppender) to give a fuller picture of the aspects to consider when using the component. It is intentionally powerful, so that users can express a wide range of routing logic, for example: - creating a separate log file per tenant or long-running job, - implementing round-robin routing between appenders. That power comes with responsibilities, and there are a couple of aspects users should review in their configuration: - **Resource allocation.** The system must be able to provision enough resources for every appender that can be created. Spinning up a separate appender per web request, for instance, is possible, but it is not a good idea: [fish tagging](https://logging.apache.org/log4j/2.x/manual/api.html#fish-tagging) log events and filtering on the tag is a far better use of resources. - **Threat model.** `RoutingAppender` is one of the components where a lookup returning untrusted data can do real damage (path traversal, SSRF, and so on). Other appenders are created to soon for lookups to contain any attacker-controlled data. It is worth pointing users back to [our threat model](https://logging.apache.org/security.html#threat-common-sources-configuration) as a reminder that they are responsible for ensuring that appender configuration attributes come from trusted sources. This is something we cannot filter out a priori: only the application developer knows which MDC keys carry validated data and which are entirely attacker-controlled. If you would like to help, a PR improving the `RoutingAppender` documentation along these lines would be very welcome. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
