Re: BUG #18828: Crash when pg_get_logical_snapshot_meta() passed empty string

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: BUG #18828: Crash when pg_get_logical_snapshot_meta() passed empty string
Дата
Msg-id 3068026.1740862032@sss.pgh.pa.us
обсуждение исходный текст
Ответ на BUG #18828: Crash when pg_get_logical_snapshot_meta() passed empty string  (PG Bug reporting form <noreply@postgresql.org>)
Ответы Re: BUG #18828: Crash when pg_get_logical_snapshot_meta() passed empty string
Re: BUG #18828: Crash when pg_get_logical_snapshot_meta() passed empty string
Список pgsql-bugs
PG Bug reporting form <noreply@postgresql.org> writes:
> Passing an empty string to the recently added extension function
> pg_get_logical_snapshot_meta() triggers PANIC / Abort.

Thanks for noticing.  It looks like this function is far too trusting
of its input.  Another way to crash it is to point to a directory:

regression=# SELECT pg_get_logical_snapshot_meta('../snapshots');
PANIC:  could not open file "pg_logical/snapshots/../snapshots": Is a directory
server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.

This example incidentally shows that it's not sanitizing the request
to prevent reference to files outside the snapshots directory, which
possibly would be a security bug down the road.  I realize that we
restrict access to the function, but still we shouldn't be *this*
trusting of the argument.

Possibly some of the defense for this ought to be in
SnapBuildRestoreSnapshot: it looks like that function isn't
considering the possibility that OpenTransientFile will succeed on a
directory.  Does it have any other callers passing
less-than-fully-trustworthy paths?

Another interesting question is why the error is being promoted
to PANIC.  That sure seems unnecessary, and there's a comment
in SnapBuildRestoreSnapshot that claims it won't happen.

            regards, tom lane



В списке pgsql-bugs по дате отправления: