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 по дате отправления: