Received: from localhost (unknown [200.46.204.184]) by postgresql.org (Postfix) with ESMTP id C99432E0FF9 for ; Fri, 21 Dec 2007 12:19:21 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.184]) (amavisd-maia, port 10024) with ESMTP id 33080-03 for ; Fri, 21 Dec 2007 12:19:15 -0400 (AST) Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by postgresql.org (Postfix) with ESMTP id 535592E3D06 for ; Fri, 21 Dec 2007 12:19:15 -0400 (AST) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.1/8.14.1) with ESMTP id lBLGIw3i005893; Fri, 21 Dec 2007 11:18:58 -0500 (EST) To: "Pavel Stehule" cc: "Merlin Moncure" , "Alvaro Herrera" , "Joshua D. Drake" , "Trevor Talbot" , "Roberts, Jon" , "Kris Jurka" , "Jonah H. Harris" , "Bill Moran" , "Pgsql Hackers" Subject: Re: function body actors (was: [PERFORM] viewing source code) In-reply-to: <162867790712210639v44a5e4f6y4640f20fbc02126d@mail.gmail.com> References: <26811.1198215605@sss.pgh.pa.us> <162867790712210018m68117783y791da209a4a97448@mail.gmail.com> <162867790712210639v44a5e4f6y4640f20fbc02126d@mail.gmail.com> Comments: In-reply-to "Pavel Stehule" message dated "Fri, 21 Dec 2007 15:39:53 +0100" Date: Fri, 21 Dec 2007 11:18:58 -0500 Message-ID: <5892.1198253938@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200712/802 X-Sequence-Number: 112091 "Pavel Stehule" writes: > On 21/12/2007, Merlin Moncure wrote: >> ... The real issue as I see it is where to >> keep the key. How did you handle that? > Simply. I use for password some random plpgsql message text and > compile it. I though about GUC, and about storing password in > postgresql.conf. It's equal to protection level. We cannot protect > code on 100%. If you have admin or superuser account and if you know > some internal, you can simply get code. Yeah. There is no defense against someone who is prepared to go in there with a debugger and pull the post-decryption code out of memory. So what we need to think about is what sorts of threats we *can* or should defend against. A couple of goals that seem like they might be reasonable are: * Even a superuser can't get the code at the SQL level, ie, it's secure if you rule out debugger-level attacks. (For example, this might prevent someone who had remotely breached the superuser account from getting the code.) * Code not available if you just look at what's on-disk, ie, you can't get it by stealing a backup tape. Any other threats we could consider defending against? BTW, this thread definitely doesn't belong on -performance anymore. regards, tom lane