From: Tom Lane <tgl@sss.pgh.pa.us>
To: Michael Paquier <michael@paquier.xyz>
Cc: Dmitry Koval <d.koval@postgrespro.ru>
Cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18274: Error 'invalid XML content'
Date: Sun, 14 Jan 2024 22:16:33 -0500
Message-ID: <1369582.1705288593@sss.pgh.pa.us> (raw)
In-Reply-To: <ZaRvbaQ8V9uGxXGD@paquier.xyz>
References: <18274-98d16bc03520665f@postgresql.org>
<1616257.1704651529@sss.pgh.pa.us>
<5588db01-45be-48ff-b158-85f789bc502c@postgrespro.ru>
<1314313.1705259848@sss.pgh.pa.us>
<0eea123f-388a-41ea-9df3-d4606cf9ed8d@postgrespro.ru>
<ZaRvbaQ8V9uGxXGD@paquier.xyz>
Michael Paquier <michael@paquier.xyz> writes:
>>> Is there some downside to XML_PARSE_HUGE?
> If one looks at the libxml2 like this mirror at [1], it is possible to
> see that the flag is only used to lift internal hard limits, for stuff
> like XML_MAX_TEXT_LENGTH and XML_MAX_NAME_LENGTH for size control, or
> max node depths.
I dug through those sources and I concur that mostly, setting that
flag just results in replacing arbitrary hard-coded limits with higher
arbitrary hard-coded limits. The one place I found where it looks
like the clamps come off entirely is that the XML_MAX_DICTIONARY_LIMIT
on the number of entries in a dictionary is replaced by "unlimited".
Given that in our usage the input string will be limited to 1GB, the
number of entries you could possibly create is still pretty finite.
> Knowing that we have full control of the memory contexts for the XML
> nodes, just enforcing the huge flag does not seem like there's any
> downside for us. (Right?)
Blowing out a backend's memory or CPU consumption is not something
we try hard to prevent, so I'm not terribly worried on that score.
The one thing I'm concerned about is that raising these limits could
make bugs (like integer overflow problems) reachable that were not
otherwise, and that such bugs might rise to the level of security
problems. They've had such issues before (CVE-2022-40303) and it'd be
foolish to be sure that none remain. Still, that's clearly their bug
not our bug.
On the whole I'm not too worried, and even if I were, I doubt that
an enabling GUC would be the answer. We'd have to make it SUSET
and default to off for it to be a credible security defense, and that
seems like an excessive amount of paranoia. Besides, I believe that
downstream packagers who don't trust libxml2 are already just building
PG without XML support.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: tgl@sss.pgh.pa.us, michael@paquier.xyz, d.koval@postgrespro.ru, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18274: Error 'invalid XML content'
In-Reply-To: <1369582.1705288593@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox