Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1VF61e-0000LR-3I for pgsql-hackers@arkaria.postgresql.org; Thu, 29 Aug 2013 17:28:54 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1VF61d-0002lM-HM for pgsql-hackers@arkaria.postgresql.org; Thu, 29 Aug 2013 17:28:53 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1VF61Z-0002ft-Rc for pgsql-hackers@postgresql.org; Thu, 29 Aug 2013 17:28:49 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1VF61X-0000R0-3M for pgsql-hackers@postgresql.org; Thu, 29 Aug 2013 17:28:49 +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 r7THScef009788; Thu, 29 Aug 2013 13:28:38 -0400 From: Tom Lane To: Josh Berkus cc: Kohei KaiGai , "ktm@rice.edu" , Alexander Korotkov , Oleg Bartunov , Greg Smith , PgHacker Subject: Re: [v9.4] row level security In-reply-to: <521F8340.6050408@agliodbs.com> References: <51E8A8C1.2050700@2ndQuadrant.com> <20130719030347.GV15510@tamriel.snowman.net> <51E8ADD9.5020600@2ndQuadrant.com> <521D1C2B.8090503@2ndQuadrant.com> <20130829142321.GA30496@aart.rice.edu> <521F7DFB.8060602@agliodbs.com> <9407.1377796701@sss.pgh.pa.us> <521F83! 40.6050408@agliodbs.com> Comments: In-reply-to Josh Berkus message dated "Thu, 29 Aug 2013 10:22:08 -0700" Date: Thu, 29 Aug 2013 13:28:38 -0400 Message-ID: <9787.1377797318@sss.pgh.pa.us> X-Pg-Spam-Score: -4.4 (----) 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 Josh Berkus writes: >> That would close only one covert channel. Others were already pointed out >> upthread, and I'll bet there are more ... > Mind you, fundamentally this is no different from allowing INSERT > permission on a table but denying SELECT, or denying SELECT on certain > columns. In either case, covert channels for some data are available. Certainly. But INSERT's purpose in life is not to prevent people from inferring what data is in the table. What we have to ask here is whether a "row level security" feature that doesn't deal with these real-world attack techniques is worth having. 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