Skip to content

Resolve XML configuration resources through ConfigurationSource#4161

Draft
ppkarwasz wants to merge 4 commits into
feat/2.x/xinclude-opt-infrom
feat/2.x/xinclude-resolver
Draft

Resolve XML configuration resources through ConfigurationSource#4161
ppkarwasz wants to merge 4 commits into
feat/2.x/xinclude-opt-infrom
feat/2.x/xinclude-resolver

Conversation

@ppkarwasz

Copy link
Copy Markdown
Member

Summary

Note

Stacked on #4158 (feat/2.x/xinclude-opt-in). Routes every external resource an XML configuration references through ConfigurationSource, the same way the configuration file itself is resolved.

A single ConfigurationSourceResolver (implementing EntityResolver + LSResourceResolver) resolves:

  • xi:include targets,
  • the validation schema (the schema attribute), and
  • the schema's own xsd:include/xsd:import resources.

As a result, all of them support the Log4j URI conventions (such as the classpath: scheme) and are subject to the log4j2.configurationAllowedProtocols restrictions, limiting the blast radius of a (trusted) configuration.

Behavior changes

  • A schema validation failure, or a resource rejected by the resolver (for example a sub-schema fetched over a disallowed protocol), now fails the configuration with a ConfigurationException instead of only logging.

Notes

  • Schema validation remains a configuration-authoring aid, not a security control: per the threat model the configuration file is trusted. The ConfigurationSource / ALLOWED_PROTOCOLS routing is defense-in-depth within that single trusted tier.
  • Tests (XmlConfigurationSchemaTest): a conforming config validates, a File appender is rejected by a Console-only schema, and an http sub-schema include is blocked by ALLOWED_PROTOCOLS; plus the existing XInclude tests.

The changelog entry's <issue> will be set to this PR number once assigned.

Resolve the resources referenced by an XML configuration through a single
`ConfigurationSourceResolver`:

* the targets of `xi:include` (as an `EntityResolver`),
* the validation schema, and
* the schema's own `xsd:include`/`xsd:import` resources (as an
  `LSResourceResolver`).

They therefore support the Log4j URI conventions (such as the `classpath:`
scheme) and obey the `log4j2.configurationAllowedProtocols` restrictions. The
schema is parsed with XInclude disabled (a schema is not a configuration), and
a schema violation or a rejected resource fails the configuration with a
`ConfigurationException`.

Assisted-By: Claude Opus 4.8 <noreply@anthropic.com>
Assisted-By: Claude Opus 4.8 <noreply@anthropic.com>
`ConfigurationSourceResolver` resolved `xi:include` targets through the
`EntityResolver` interface, whose `resolveEntity(publicId, systemId)` lacks the
base URI, so a parser that passes an unresolved, relative `systemId` (such as
the target of a nested `xi:include`) could not be satisfied. Implement
`EntityResolver2` so the resolver receives the base URI and resolves the
`systemId` against it, the same way `resolveResource` already does for schema
imports.

Assisted-By: Claude Opus 4.8 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Development

Successfully merging this pull request may close these issues.

1 participant