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