Re: Security leak with trigger functions?

From: "Florian G(dot) Pflug" <fgp(at)phlo(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Martijn van Oosterhout <kleptog(at)svana(dot)org>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Albe Laurenz <all(at)adv(dot)magwien(dot)gv(dot)at>, Peter Eisentraut *EXTERN* <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Security leak with trigger functions?
Date: 2006-12-17 21:18:01
Message-ID: 4585B409.6080508@phlo.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> Martijn van Oosterhout <kleptog(at)svana(dot)org> writes:
>> The trigger never runs as the owner of the table AIUI, only ever as the
>> definer of the function or as session user.
>
> Yeah. This might itself be seen as a bug: I think you could make a
> reasonable case that the default behavior ought to be to run as the
> table owner (but still overridable if trigger function is SECURITY
> DEFINER, of course). In the current situation a table owner can use
> a trigger function as a trojan horse against anyone modifying the
> table.

Is this true for on-select rules too? In that case, couldn't any
user run his code as postmaster by creating an appropriate on-select
rule and waiting until somebody/cron backups the database using pg_dump?

Or is pg_dump smart enough to skip dumping tables with on-select rules?

greetings, Florian Pflug

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2006-12-18 00:44:19 Re: Security leak with trigger functions?
Previous Message Andrew Dunstan 2006-12-17 20:28:12 Re: [PATCHES] psql commandline conninfo