-----Original Message-----
From: "Peter Eisentraut"<peter_e@gmx.net>
Sent: 10/04/06 22:43:05
To: "Bruce Momjian"<pgman@candle.pha.pa.us>
Cc: "Dave Page"<dpage@vale-housing.co.uk>, "pgsql-hackers@postgresql.org"<pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Remote administration contrib module
> If there are _security_ issues, they need to be fixed
> before things go into contrib.
(From memory) There were concerns, rather than actual issues. The functions are all superuser-only where appropriate,
andwhile the only potentially destructive ones (pg_file_write, pg_file_rename, pg_file_unlink) can kill files under
$PGDATA- but then, so can COPY just as easily.
> > This is similar to the fact we don't include plpgsql by default in
> > databases, for the same reason,
> I doubt that that is really the reason.
It's the only reason I ever heard.
/D
-----Unmodified Original Message-----
Bruce Momjian wrote:
> I think the issue was that adding these fuctions adds a potential
> security opening, so we didn't want it in core by default, but
> /contrib seems logical because anyone who needs it can just add it.
Well, if there are security issues, then this is a poor fix. A lot of
people use pgAdmin, many of them less experienced with PostgreSQL, so
before long all of these functions are going to be installed at many
sites anyway. If there are _security_ issues, they need to be fixed
before things go into contrib.
> This is similar to the fact we don't include plpgsql by default in
> databases, for the same reason,
I doubt that that is really the reason.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/