Received: from localhost (unknown [200.46.204.191]) by postgresql.org (Postfix) with ESMTP id 465012E0137 for ; Fri, 21 Dec 2007 18:07:42 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.191]) (amavisd-maia, port 10024) with ESMTP id 73054-03 for ; Fri, 21 Dec 2007 18:07:37 -0400 (AST) Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by postgresql.org (Postfix) with ESMTP id EEC132E0058 for ; Fri, 21 Dec 2007 18:07:37 -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 lBLM7R2o012875; Fri, 21 Dec 2007 17:07:27 -0500 (EST) To: "Trevor Talbot" cc: pgsql-performance@postgresql.org, "Merlin Moncure" , "Alvaro Herrera" , "Joshua D. Drake" , "Roberts, Jon" , "Kris Jurka" , "Jonah H. Harris" , "Bill Moran" Reply-to: pgsql-hackers@postgresql.org Subject: Re: viewing source code In-reply-to: <90bce5730712211102n3232b0abg8a20226037e7287e@mail.gmail.com> References: <1A6E6D554222284AB25ABE3229A92762112A33@nrtexcus702.int.asurion.com> <476A9ADF.5030101@commandprompt.com> <90bce5730712201047m4dd0fe05k6b1fccc57897326f@mail.gmail.com> <20071220114011.64a650d7@commandprompt.com> <20071220200739.GC11586@alvh.no-ip.org> <20377.1198191718@sss.pgh.pa.us> <90bce5730712211102n3232b0abg8a20226037e7287e@mail.gmail.com> Comments: In-reply-to "Trevor Talbot" message dated "Fri, 21 Dec 2007 11:02:43 -0800" Date: Fri, 21 Dec 2007 17:07:27 -0500 Message-ID: <12874.1198274847@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200712/350 X-Sequence-Number: 28166 "Trevor Talbot" writes: > Something that looks a lot like encryption of the entire database is > more likely to succeed politically than a simple addition to > PostgreSQL's existing role-based security model? Really? I guess that you have failed to understand any of the discussion. Adding a GRANT SEESOURCECODE ON FUNCTION type of privilege would perhaps be a "simple addition to PostgreSQL's existing security model", but it would accomplish precisely zero, because anyone smart enough to be using Postgres in the first place would simply look directly into pg_proc to see the function body. In order to make it into a meaningful restriction, we would have to restrict direct SQL access to the system catalogs --- at least that one --- which would break vast quantities of stuff. The fact that psql, pg_dump, and pgAdmin would all break is daunting in itself, but those are likely just the tip of the iceberg. Looking at the system catalogs has always been part of the culture around here, and it's impossible to guess how many one-off client programs do it. I'd bet on "a lot", though. Another problem is that you're facing a cultural bias. You quote > On 12/14/07, Roberts, Jon wrote: >> In an ideal world, if a user can't modify a function, he/she shouldn't be >> able to see the source code. but what neither of you apparently grasp is that to most open source programmers, that's not an "ideal world", that's a pretty good description of hell on earth. There is no way that you will persuade this project that hiding source code should be the default behavior, or even especially easy. We're willing to think about ways to hide source code where there is a really serious commercial imperative to do it --- but in cases like that, schemes that are as easily broken into as a SQL-level GRANT are probably not good enough anyhow. And thus we arrive at encrypted source text and discussions of where to keep the key. Once again: this discussion is 100% off-topic for pgsql-performance. If you want to keep talking about it, please join the child thread on pgsql-hackers. regards, tom lane