From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | pgsql-hackers(at)postgresql(dot)org, Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Subject: | Re: pg_pltemplate entries for external PLs |
Date: | 2008-12-31 16:01:25 |
Message-ID: | 26889.1230739285@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> On Wednesday 31 December 2008 05:50:19 Tom Lane wrote:
>> That was part of the original concept for pg_pltemplate, but IIRC there
>> was push-back from some folks who thought it was a bad idea. I don't
>> recall what their arguments were exactly;
> Basically, we have no information about what the proper parameters of external
> languages would be. (We have some pretty good ideas, but that's not the
> same.) Especially if we override the trusted/untrustedness, we could create
> complete disaster.
Presumably we'd only insert such entries with the concurrence/approval
of the PL's author, so this argument seems pretty darn weak to me.
It's true that we could have another fiasco like the trusted-plpython
one, where something that we thought was trustworthy turns out not to
be; but pg_pltemplate seems unlikely to make such a case much worse than
it is already. The people who'd be at risk would be the ones who'd
already installed the unsafe language, and where they got the
information that it was safe wouldn't be relevant anymore.
On the other hand, having entries for non-built-in languages in
pg_pltemplate would clearly reduce the chances of DBAs accidentally
creating a language as trusted when it should not be. I think the odds
are good that this effect would reduce security risks far more than
they'd be increased by the chance of bad entries in pg_pltemplate.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-12-31 16:04:41 | Re: TODO items for window functions |
Previous Message | Alvaro Herrera | 2008-12-31 15:54:07 | Re: version() output vs. 32/64 bits |