[
https://issues.apache.org/jira/browse/LOG4J2-3480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17524435#comment-17524435
]
Matt Sicker commented on LOG4J2-3480:
-------------------------------------
I'm glad to see a realistic use case of advanced variable usage. I had
initially thought that something like this might happen. Historically, variable
expansion was done recursively, though that also means there were ways to cause
a StackOverflowError by using self-referential variables and default values.
While I think we've covered the security significant cases by removing the
pattern converter overlap with variable substitution (which I still think was
an accidental "feature" that was never documented until last year in the first
place), the additional hardening to ensure that variable interpolation isn't
done so greedily is still something subject to fine tuning.
> Changed behaviour (regression) in 2.17.2 lookup plugin or string interpolation
> ------------------------------------------------------------------------------
>
> Key: LOG4J2-3480
> URL: https://issues.apache.org/jira/browse/LOG4J2-3480
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
> Affects Versions: 2.17.2
> Reporter: K P
> Priority: Major
> Labels: interpolation, lookup, regression
>
> Something (breaking) changed in the way lookups and/or string interpolation
> is done, between versions 2.17.1 and {*}2.17.2{*}.
> Our situation has some complexities (for historical reason):
> * we can use {_}either a configuration via log4j2.xml file{_},
> or either the same _config built programmatically_
> * we have a {_}custom lookup plugin{_}. Let's call it "foo" for the purpose
> of illustration:
> {{@Plugin(name = "foo", category = "Lookup")}}
> The lookup has a few keys.
> * e.g.: _${foo:version}_ , _${foo:options}_ , etc.
> (reason or underlying implementation doesn't matter here - something to do
> with context based on dynamic modules, threadgroups, etc)
> * The lookup also has the keys _${foo:header}_ and _${foo:footer}_ , which
> contains a larger snippet, INCLUDING some of its other keys.
> e.g. (simplified adapted example)
> "Here some header text for version $${foo:version} at ** $${date} etc etc"
> These double $$ are important here , see further below.
> Then we have in our <PatternLayout> configuration the following:
> {{ <PatternLayout>}}
> {{ <Pattern>... omitted here ...</Pattern<}}
> {{ <Header>${foo:header}</Header>}}
> {{ <Footer>${foo:footer}</Footer>}}
>
>
> As a result, each logfile is started with the well-defined header snippet
> (this string hard-coded inside the lookup plugin), but that header has some
> variable content (${foo:version}, ${foo:options}, ${date} ), which is
> substituted in turn. And each logfile is terminated by the foo:footer. Having
> this header and footer defined by the lookup ensures that the end-user easily
> configures them in the fixed header and footer in his log4j2.xml.
> Now in our application we also allow a +programmatically built log+
> configuration:
> {{ builder.newLayout("PatternLayout")}}
> {{ .addAttribute("header", HEADER)}}
> {{ .addAttribute("header", FOOTER)}}
> whereby HEADER and FOOTER are the same strings as returned by our custom foo
> lookup plugin when it returns foo:header and foo:footer. (i.e. containing the
> double $$ inside)
> +Why the double $$ ?+
> We have these since many years: The double $$ ensure that the lookups
> included inside the header and footer (e.g. $${foo:version}, but also the
> $${date} ) +are evaluated at the time that the logfile is actually being
> written+ !
> If instead we used a single $ inside the header and footer, the interpolation
> happened only 1x at time of configuration. Which is not what we want.
> e.g. when using a single $, then the timestamp in the header was stuck to
> the timestamp at the time that our application _loaded the logging config._
> Whereas of course we'd want the timestamp to be current at the time the new
> logfile was created.
> If I remember well, the same was true for our custom lookup: to ensure it
> being {+}re{+}-evaluated at the time the logfile was written, we needed to
> use a double $$.
>
> Now this {+}worked fine up until log4j 2.17.1{+}.
> +both+ with our _programmatic_ configuration or when configured via
> _log4j2.xml_
> This _still_ works in log4j 2.17{*}.2{*} when we are running with our
> *programmatically* built configuration:
> However, in log4j 2.17.2 this *no longer* works when the configuration is
> taken from the *log4j2.xml* file.
> In that case, the expansion of double $${...} no longer works.
> Instead, it just prints something like: "{{{}Here some header text for
> version ${foo:version} at ${date} etc{}}}"
> i.e. the double $$ is substituted by a single $ now, but now _no_ further
> substitution are done. Not at load time, not later at write time.
> On the other hand, when in the header string, I now use $ inside $$, then
> this now suddenly works in the log4j2.xml-based configuration with
> substitution at write-time. Which is clearly a different behavior than up to
> log4j 2.17.1. And is also a different behavior than the programmatic
> configuration.
>
> So there's clearly +something+ has changed unexpectedly in log4j 2.17.2...
> I don't know which change or jira issue may have caused it ?
> Could it have something to do with, which did some changes in the string
> interpolation? LOG4J2-3424 ?
> Or can it be related to e.g. LOG4J2-3470 ?
> Something else?
>
> I did try using the 2.17.3-SNAPSHOT, but I am still seeing the changed 2.17.2
> behavior there...
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
