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