| From: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
|---|---|
| To: | Merlin Moncure <mmoncure(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: emergency outage requiring database restart |
| Date: | 2016-10-26 20:06:34 |
| Message-ID: | ad10e8d7-da64-789e-9e69-44abcadc00ef@BlueTreble.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 10/26/16 2:25 PM, Merlin Moncure wrote:
> I don't think that's the case. sqsh is a psql-like utility. it
> writes to stdout and stderr only which is captured by plsh and sent.
> In this context shexec only wraps rm -f 'file' where 'file' is a file
> previously created with COPY in the same transaction.
How do you know that? It could potentially be doing anything it wanted
with file handles. Removing the exec might "solve" the problem here,
assuming that the forked process doesn't still inherit all open FH's.
In a nutshell, running arbitrary shell code (let alone arbitrary
executables) in a pl that's running inside the Postgres backend sounds
insanely risky to me.
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532) mobile: 512-569-9461
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2016-10-26 20:11:58 | Re: pg_hba_file_settings view patch |
| Previous Message | Joshua D. Drake | 2016-10-26 20:04:15 | Re: pg_hba_file_settings view patch |