Re: pl/pgsql enabled by default
Mike Mascari <mascarm@mascari.com>
From: Mike Mascari <mascarm@mascari.com>
To: Andrew Dunstan <andrew@dunslane.net>
Cc: Neil Conway <neilc@samurai.com>, Andrew Sullivan <ajs@crankycanuck.ca>, pgsql-hackers@postgresql.org
Date: 2005-05-08T02:49:24Z
Lists: pgsql-hackers
Andrew Dunstan wrote: > > > Mike Mascari wrote: > but the side effect function will only run (unless you set it with > security definer) with the privileges of the caller - it won't grant > visibility to things that user can't otherwise see. If the visibility is determined by view definitions, such as using CURRENT_USER, which is an exceedingly common practice, then the caller will be able to record tuples before they are filtered by the executor. > In any case, you should define your security setup with the > capabilities / limitations of the db engine in mind. If there is any > security problem in your scenario, it is that you appear to have made > unwarranted assumptions about how postgres works, rather than that > postgres has a problem. I think most people coming from any other enterprise-class RDBMS environment will be surprised that they cannot use VIEWs to provide user-specific views on data. I could be wrong, but I'd put money on it... > Either way, this does not illustrate how enabling plpgsql by default is > a security risk. Correct, as the vulnerability exists within the 'SQL' language as well. The only difference is that enabling plpgsql by default changes it from a leak to a full blown flood. Mike Mascari