Added to TODO: > * Tighten trigger permission checks > > http://archives.postgresql.org/pgsql-hackers/2006-12/msg00564.php
and: > * Tighten function permission checks > > http://archives.postgresql.org/pgsql-hackers/2006-12/msg00568.php > --------------------------------------------------------------------------- Tom Lane wrote: > "Florian G. Pflug" <[EMAIL PROTECTED]> 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 > > ---------------------------(end of broadcast)--------------------------- > TIP 5: don't forget to increase your free space map settings -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
