Re: pl/pgsql enabled by default

From: Mike Mascari <mascarm(at)mascari(dot)com>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Neil Conway <neilc(at)samurai(dot)com>, Andrew Sullivan <ajs(at)crankycanuck(dot)ca>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: pl/pgsql enabled by default
Date: 2005-05-08 02:49:24
Message-ID: 427D7E34.6040300@mascari.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Neil Conway 2005-05-08 02:54:22 Re: pl/pgsql enabled by default
Previous Message Bruce Momjian 2005-05-08 02:41:30 Re: Race conditions, race conditions!