Обсуждение: Re: [PATCHES] Warning for missing createlang
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Peter Eisentraut wrote:
>> Bruce Momjian writes:
>>> I don't mind the maintenance. I just want people to stop getting stuck
>>> creating plpsql functions.
>>
>> Then put plpgsql in the default installation.
> Fine with me. I thought others didn't want it.
There are good security arguments not to have it in the default install,
no? I certainly don't think that avoiding having grotty coding for a
hint is an argument that trumps our past reasons not to do it.
regards, tom lane
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Peter Eisentraut wrote: > >> Bruce Momjian writes: > >>> I don't mind the maintenance. I just want people to stop getting stuck > >>> creating plpsql functions. > >> > >> Then put plpgsql in the default installation. > > > Fine with me. I thought others didn't want it. > > There are good security arguments not to have it in the default install, > no? I certainly don't think that avoiding having grotty coding for a > hint is an argument that trumps our past reasons not to do it. Yes, of course they are independent arguments. Jan isn't comfortable with it being included, and I think that is what has kept it out. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Tom Lane writes: > There are good security arguments not to have it in the default install, > no? I think last time the only reason we saw was that dump restoring would be difficult. I don't see any security reasons. -- Peter Eisentraut peter_e@gmx.net
Peter Eisentraut wrote: >Tom Lane writes: > > > >>There are good security arguments not to have it in the default install, >>no? >> >> > >I think last time the only reason we saw was that dump restoring would be >difficult. I don't see any security reasons. > That could be overcome by doing a 'drop language' before running your restore, couldn't it? Maybe it would also be useful for such cases to have a switches on initdb and pg_dump to inhibit creation of the language. I did see a reference in the archives to a problem with heavy recursion as a possible security hole. I guess my answer to that would be that if you are worried about it you should drop the language, but I don't see this alone as a reason not to install it by default. After all, you don't need plpgsql to bring the system to its knees :-) But maybe there's some other reason my search didn't find. cheers andrew
Andrew Dunstan <andrew@dunslane.net> writes:
> I did see a reference in the archives to a problem with heavy recursion
> as a possible security hole. I guess my answer to that would be that if
> you are worried about it you should drop the language, but I don't see
> this alone as a reason not to install it by default. After all, you
> don't need plpgsql to bring the system to its knees :-)
Yeah, now that we allow recursion in SQL functions, you don't need a PL
language to overflow the stack. So that particular argument is seeming
a bit weak. Were there any other security arguments against making
plpgsql standard?
Inability to load existing pg_dump archives might be a bigger objection.
However, we could fix that if pg_restore were modified to not stop dead
in its tracks upon encountering an error. IMHO that was a wrong choice
from the beginning ... pg_dump scripts don't act that way, and
pg_restore should not either.
regards, tom lane
Andrew Dunstan kirjutas L, 06.09.2003 kell 16:14: > Peter Eisentraut wrote: > > >Tom Lane writes: > > > > > > > >>There are good security arguments not to have it in the default install, > >>no? > >> > >> > > > >I think last time the only reason we saw was that dump restoring would be > >difficult. I don't see any security reasons. > > > > That could be overcome by doing a 'drop language' before running your > restore, couldn't it? or to have CREATE OR REPLACE LANGUAGE (like we have for FUNCTIONS). ------------------- Hannu