On Mon, Aug 19, 2013 at 10:21 AM, Dimitri Fontaine
<dimitri@2ndquadrant.fr> wrote:
> Dave Page <dpage@pgadmin.org> writes:
>> The escalation happens because in a normal system-wide installation of
>> PostgreSQL as you'd see on most production systems will have the
>> installation directories and binaries owned by the root user, so if
>> the server or a superuser account on it is compromised, the attacker
>> still can't (easily) modify the PostgreSQL installation to do Bad
>> Things, assuming the sysadmin has disabled untrusted PLs.
>
> I appreciate that line of arguments, but it's been proven more than once
> (last time by Andres) to be just false. Given a malicious user with
> superuser privileges on a standard PostgreSQL backend without any
> extension nor PL installed, arbitrary code execution is already possible
> and quite easy to achieve.
>
> Given how easy it is, that whole line of thoughs really is moot.
If you find a hole in the boat, the preferred option is to fix it, not
to say "meh, well another won't hurt".
>> I can see the use case for the change suggested, but I feel pretty
>> strongly that it should not be allowed in a default configuration, and
>> should be something that can be disabled from outside of
>> postgresql.conf (which of course, can often be modified through
>> PostgreSQL by a superuser - and yes, I realise there is risk there
>> too, but no sense adding to that).
>
> My proposal here would be in the lines of a dynamic GUC where you could
> add directories to consider at LOAD time (including .so dependencies
> resolution, that's the main trick). That GUC would default to being
> empty, which should answer your valid concern here.
That wouldn't address my concern, which is preventing someone with
only DB server superuser access from enabling the feature.
--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
