Skip site navigation (1) Skip section navigation (2)

Re: Security leak with trigger functions?

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Florian G(dot) Pflug" <fgp(at)phlo(dot)org>, 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: 2007-02-01 04:52:30
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Added to TODO:

> * Tighten trigger permission checks


> * Tighten function permission checks


Tom Lane wrote:
> "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
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings

  Bruce Momjian   bruce(at)momjian(dot)us

  + If your life is a hard drive, Christ can be your backup. +

In response to

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2007-02-01 05:14:03
Subject: Re: [HACKERS] Typo in pg_dump documentation and new suggestion for Release Notes
Previous:From: Bruce MomjianDate: 2007-02-01 04:41:09
Subject: Re: pg_restore fails with a custom backup file

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group