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
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! |