Re: [HACKERS] Updating column on row update
Andrew Gierth <andrew@tao11.riddles.org.uk>
From: Andrew Gierth <andrew@tao11.riddles.org.uk>
To: tgl@sss.pgh.pa.us (Tom Lane), PGSQL Mailing List <pgsql-general@postgresql.org>, pgsql-hackers@postgresql.org
Cc: Thom Brown <thombrown@gmail.com>, Robert Haas <robertmhaas@gmail.com>, Craig Ringer <craig@postnewspapers.com.au>, Scott Marlowe <scott.marlowe@gmail.com>
Date: 2009-11-23T15:24:00Z
Lists: pgsql-hackers, pgsql-general
>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes: > Thom Brown <thombrown@gmail.com> writes: >> As for having plpgsql installed by default, are there any security >> implications? Tom> Well, that's pretty much exactly the question --- are there? It Tom> would certainly make it easier for someone to exploit any other Tom> security weakness they might find. I believe plain SQL plus SQL Tom> functions is Turing-complete, but that doesn't mean it's easy or Tom> fast to write loops etc in it. Now that we have recursive CTEs, plain SQL is turing-complete without requiring functions. (Yes, I did actually prove this a while back, by implementing one of the known-Turing-complete tag system automata as a single recursive query. This proof is pretty boring, though, because you wouldn't actually _use_ that approach in practice.) Loops in plain SQL are no problem: see generate_series. The last time we discussed this I demonstrated reasonably straightforward SQL examples of how to do things like password-cracking (and that was long before we had CTEs, so it would be even easier now); my challenge to anyone to produce examples of malicious plpgsql code that couldn't be reproduced in plain SQL went unanswered. -- Andrew (irc:RhodiumToad)