SEO

#1 (**permalink**) 04-09-2008, 07:50 AM

Or more specifically, what are the security implications of a trigger
written in an untrusted language - PL/PerlU?

With a standard stored procedure, you have the possibility of an
SQL-injection attack. Is this possible with a trigger function, if it is
defined as a trigger?

I am writing a couple of Perl modules that talk to the outside world: one
talks to a database (via DBI), and one talks to a Jabber/XMPP server. I
want to use these from within a Trigger. Do I have to taint-check the
input provided by the trigger mechanism - or does PG do this?

Thanks,
-Josh

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

#2 (**permalink**) 04-09-2008, 07:50 AM

Joshua Kramer <josh@bitbuckets.com> writes:
> I am writing a couple of Perl modules that talk to the outside world: one
> talks to a database (via DBI), and one talks to a Jabber/XMPP server. I
> want to use these from within a Trigger.

This is most likely a bad idea for reasons that have nothing to do with
security. Consider what happens when the trigger executes and later in
the transaction there's an error, causing the whole transaction to roll
back. Now the outside world has changed state and your database has
not.

It's usually better to have an application process that is in charge of
monitoring database state and updating external stuff to match. See the
archives for many previous discussions of this point.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

SEO

Security implications of untrusted triggers