pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Josh Berkus <josh@agliodbs.com>
Cc: Kohei KaiGai <kaigai@kaigai.gr.jp>
Cc: ktm@rice.edu <ktm@rice.edu>
Cc: Alexander Korotkov <aekorotkov@gmail.com>
Cc: Oleg Bartunov <obartunov@gmail.com>
Cc: Greg Smith <greg@2ndquadrant.com>
Cc: PgHacker <pgsql-hackers@postgresql.org>
Subject: Re: [v9.4] row level security
Date: Thu, 29 Aug 2013 13:28:38 -0400
Message-ID: <9787.1377797318@sss.pgh.pa.us> (raw)
In-Reply-To: <521F8340.6050408@agliodbs.com>
References: <51E8A8C1.2050700@2ndQuadrant.com>
	<20130719030347.GV15510@tamriel.snowman.net>
	<51E8ADD9.5020600@2ndQuadrant.com>
	<CAEZATCXdj4E8uPHxq7jiE=1gGVB0xyeHtE8wUjHoX385sHhx4Q@mail.gmail.com>
	<CADyhKSWw1RY01tyuhRzu2HAa_+B9Z5qS6Jv+HEA1w0C9Ua2QLQ@mail.gmail.com>
	<521D1C2B.8090503@2ndQuadrant.com>
	<CAF4Au4xDXzACfC_KrXXpu=4et3XhUe5NtK=6y6yq39Cs2U0XKg@mail.gmail.com>
	<CADyhKSWkHrPqbRsFK0LjPMOOTsbKGWOuN75GqYJrxCDO3CKWtA@mail.gmail.com>
	<CAPpHfdsgMrBnzu9um48O6kwY=_pRFuRrBrHqnA03fCAo8x3-Gg@mail.gmail.com>
	<CADyhKSUpcYKNm3rQRwCFqkTZfO3_ZrqYKjAqDxKeA6WeLezSbw@mail.gmail.com>
	<20130829142321.GA30496@aart.rice.edu>
	<CADyhKSUD7qdQeTndZ6mDpp05V6MnRBzQO1FmYBq1+Zp37oyRrg@mail.gmail.com>
	<WM!685df689dd4d8f8c5349d5ef7b8e285db1e99ea32d22ab5d35f3981c29eac19dbd725c9b5e0227def9d782de274d1354!@asav-3.01.com>
	<521F7DFB.8060602@agliodbs.com>
	<9407.1377796701@sss.pgh.pa.us>
	<WM!b776adf5b5f415ff9a8c49026fe72462f8b32852bb3327d6185064e91ae314e93bda384c75db979881f53ae4e36664a7!@asav-1.01.com>
	<521F83! 40.6050408@agliodbs.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>

Josh Berkus <josh@agliodbs.com> 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



view thread (165+ messages)  latest in thread

Message-ID: <9787.1377797318@sss.pgh.pa.us>
Permalink:  ../9787.1377797318@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/9787.1377797318@sss.pgh.pa.us

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: tgl@sss.pgh.pa.us, josh@agliodbs.com, kaigai@kaigai.gr.jp, ktm@rice.edu, aekorotkov@gmail.com, obartunov@gmail.com, greg@2ndquadrant.com
  Subject: Re: [v9.4] row level security
  In-Reply-To: <9787.1377797318@sss.pgh.pa.us>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox