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
