Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1VFUbX-0006yB-SI for pgsql-hackers@arkaria.postgresql.org; Fri, 30 Aug 2013 19:43:36 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1VFUbX-0002j8-9I for pgsql-hackers@arkaria.postgresql.org; Fri, 30 Aug 2013 19:43:35 +0000 Received: from makus.postgresql.org ([2001:4800:7903:4::125]) by malur.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1VFUbU-0002iw-M5 for pgsql-hackers@postgresql.org; Fri, 30 Aug 2013 19:43:32 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1VFUbO-0007nU-4z for pgsql-hackers@postgresql.org; Fri, 30 Aug 2013 19:43:32 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id r7UJhE9f016799; Fri, 30 Aug 2013 15:43:14 -0400 From: Tom Lane To: Stephen Frost cc: Josh Berkus , Kohei KaiGai , "ktm@rice.edu" , Alexander Korotkov , Oleg Bartunov , Greg Smith , PgHacker Subject: Re: [v9.4] row level security In-reply-to: <20130830192729.GO2706@tamriel.snowman.net> References: <20130829142321.GA30496@aart.rice.edu> <521F7DFB.8060602@agliodbs.com> <5220D832.7090104@agliodbs.com> <20130830192729.GO2706@tamriel.snowman.net> Comments: In-reply-to Stephen Frost message dated "Fri, 30 Aug 2013 15:27:29 -0400" Date: Fri, 30 Aug 2013 15:43:14 -0400 Message-ID: <16798.1377891794@sss.pgh.pa.us> X-Pg-Spam-Score: -4.1 (----) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Stephen Frost writes: > We have issues with covert channels even without RLS though and holding > up RLS because it doesn't fix all the covert channels isn't sensible. I think it's entirely sensible to question whether we should reject (not "hold up") RLS if it has major covert-channel problems. The scenario I'm worried about is where somebody says "hey, Postgres has RLS now, I can rely on that to hide my sooper sekrit data from other users in the same database", and later they have a security breach through some covert-channel attack. Are they going to blame themselves? No, they're gonna blame Postgres. Or consider the case where some bozo publishes a method for such an attack and uses it to badmouth us as insecure. I don't think we need the headaches that will result from promising (or at least appearing to promise) something we can't deliver. Nor am I convinced that we're really doing users any favors by providing such a feature. They'd be *far* better advised to put their critical data in a separate database. In short, "we can check some check-box" is a really, really bad reason to accept a security-related feature. If we're going to put up with all the downsides of RLS, I want the end result to be something that's actually secure, not something that gives the illusion of security. And right now, I do not believe we can get past the illusion stage, ever (certainly not in a release or two). regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers