From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Florian G(dot) Pflug" <fgp(at)phlo(dot)org> |
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-18 00:44:19 |
Message-ID: | 19716.1166402659@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Florian G. Pflug" <fgp(at)phlo(dot)org> writes:
> 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?
I don't see any issue for views' on-select rules; they wouldn't get
executed during either dump or reload.
It does seem like there are some other potential hazards once you start
thinking this way:
* Datatype I/O functions: the output function will be run as superuser
during pg_dump, and the input function during restore. I think this is
not an attack spot today because I/O functions can only be written in
C, but we'd have to think about the consequences before allowing I/O
functions in trusted P/L languages. (Perhaps arrange for I/O functions
to be run as if setuid to their owner? Could be expensive...)
* Functions associated with indexes would get run during restore:
both the datatype-related index support functions, and any functions
used in functional indexes. This might be OK because we require
such functions to be immutable, but I do not think the link from
"immutable" to "can't write database" is currently air-tight.
* Functions in CHECK constraints (either table or domain constraints)
would be executed during restores. There is not an immutability
constraint for these currently, although arguably it'd be reasonable
to require?
* Trigger functions: not executed during pg_dump, nor during a full
restore, but they *would* be executed during a data-only restore if
you'd not used --disable-triggers.
* ON INSERT rules: likewise, executed during data-only restores,
possibly resulting in execution of user-defined functions.
During restores, we normally set the userid to be the table owner while
loading data into a particular table, which would mostly close these
holes except that I think a function can revert the session
authorization to be whatever the outermost user id is. Probably we need
to tighten up the conditions under which a SET SESSION AUTHORIZATION can
be reverted within a function.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Hiroshi Saito | 2006-12-18 01:27:06 | Re: pgsql: Put JST back into the default set of timezone abbreviations; was |
Previous Message | Florian G. Pflug | 2006-12-17 21:18:01 | Re: Security leak with trigger functions? |