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.
> 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.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
