Received: from localhost (unknown [200.46.204.187]) by postgresql.org (Postfix) with ESMTP id 245B62E35A5 for ; Fri, 21 Dec 2007 16:56:49 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.187]) (amavisd-maia, port 10024) with ESMTP id 81610-10 for ; Fri, 21 Dec 2007 16:56:39 -0400 (AST) Received: from main2.mycybernet.net (main2.mycybernet.net [209.222.63.140]) by postgresql.org (Postfix) with ESMTP id AA6762E0355 for ; Fri, 21 Dec 2007 16:56:42 -0400 (AST) Received: from 227-54-222-209.mycybernet.net ([209.222.54.227] helo=crankycanuck.ca) by main2.mycybernet.net with esmtp (Exim 4.62) (envelope-from ) id 1J5ouw-0006Ey-FQ for pgsql-hackers@postgresql.org; Fri, 21 Dec 2007 15:56:26 -0500 Received: by crankycanuck.ca (Postfix, from userid 1000) id 9DFC3500AD; Fri, 21 Dec 2007 15:56:19 -0500 (EST) Date: Fri, 21 Dec 2007 15:56:19 -0500 From: Andrew Sullivan To: pgsql-hackers@postgresql.org Subject: Re: function body actors (was: [PERFORM] viewing source code) Message-ID: <20071221205619.GD3864@crankycanuck.ca> Mail-Followup-To: Andrew Sullivan , pgsql-hackers@postgresql.org References: <26811.1198215605@sss.pgh.pa.us> <20071221164826.GI10918@crankycanuck.ca> <10257.1198263464@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <10257.1198263464@sss.pgh.pa.us> User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200712/810 X-Sequence-Number: 112099 On Fri, Dec 21, 2007 at 01:57:44PM -0500, Tom Lane wrote: > "Merlin Moncure" writes: > > ISTM the main issue is how exactly the authenticated user interacts > > with the actor to give it the information it needs to get the real > > key. This is significant because we don't want to be boxed into an > > actor implementation that doesn't allow that interaction. > > We don't? What purpose would such a setup serve? I would think > that for the applications we have in mind, the *last* thing you > want is for the end user to hold the key. The whole point of this > is to keep him from seeing the function source code, remember? Hmm; this may be exactly part of the problem, though. It seems there are two possible cases in play: 1. Protect the content in the database (in this case, function bodies) from _all_ users on a given server. This is a case where you want to protect (say) your function body from your users, because you have a closed-source application. 2. Protect the content of a field from _some_ users on a given system, based on the permissions they hold. This is roughly analagous to others not being able to look in the table I created, because I haven't GRANTed them permission. (2) is really a case for column-level access controls, I guess. But if we're trying to solve this problem too, then user passwords or something make sense. A