From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Andrew Hammond" <andrew(dot)george(dot)hammond(at)gmail(dot)com>, "Andrew Sullivan" <ajs(at)crankycanuck(dot)ca>, <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Bugtraq: Having Fun With PostgreSQL |
Date: | 2007-06-26 21:43:24 |
Message-ID: | 87ir9atmrn.fsf@oxford.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> Gregory Stark <stark(at)enterprisedb(dot)com> writes:
>> All that really has to happen is that dblink should by default not be
>> callable by any user other than Postgres.
>
> Yeah, that is not an unreasonable change. Someone suggested it far
> upthread, but we seem to have gotten distracted :-(
On the subject of privilege escalation in contrib modules, I just did some
quick searches. Other modules using suspect calls are: pg_adminpack, and
tsearch2 (aside from pg_standby and pgbench which are stand-alone programs).
It looks like pg_adminpack uses requireSuperuser religiously so that should be
fine.
tsearch2 looks kind of suspect though. I'm not very familiar with it but is
there any protection against an attacker specifying arbitrary files as
dictionary, thesaurus, or stemmer files, allowing the user to open a file as
the postgres user instead of his own privileges?
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-06-26 22:05:04 | pgsql: Fix PGXS conventions so that extensions can be built against |
Previous Message | Stephen Frost | 2007-06-26 21:30:21 | Re: Bugtraq: Having Fun With PostgreSQL |