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

help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alexander Korotkov <aekorotkov@gmail.com>
Cc: Kohei KaiGai <kaigai@kaigai.gr.jp>
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 10:05:14 -0400
Message-ID: <4142.1377785114@sss.pgh.pa.us> (raw)
In-Reply-To: <CAPpHfdsgMrBnzu9um48O6kwY=_pRFuRrBrHqnA03fCAo8x3-Gg@mail.gmail.com>
References: <CADyhKSUq+BHPAEdrNQXy_bFSzz2SG29vzJmDUh4p20iWje8QSg@mail.gmail.com>
	<CADyhKSVNMMvmPCQkpaVb96T4F3Eu+uREnak4_5_5RLOuSeJLQg@mail.gmail.com>
	<CADyhKSXFzQBXQoNwiKdN9xxoVw7Zqz9gmF64Sry57QKduSFwSQ@mail.gmail.com>
	<CANPAkgtgZbOE5-iU17Gy+_YWODe5UBsfZg6+rk2v=bNQRo0wgA@mail.gmail.com>
	<CADyhKSVoCHMnnGX0Z2b8dgfCUoE1XGdtbAz2HXE4+Q3ajgoxrQ@mail.gmail.com>
	<CANPAkgvcL+w2scZqEcXwX5-TMe9EEORLcHDesJeTn8yoZsc0=g@mail.gmail.com>
	<51E880CF.3000902@gmail.com>
	<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>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>

Alexander Korotkov <aekorotkov@gmail.com> writes:
> On Wed, Aug 28, 2013 at 4:17 PM, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote:
>> It is out of scope for this feature. We usually calls this type of
>> information leakage "covert channel"; that is not avoidable in principle.

> I think there is another "covert channel" much more serious than
> constrains. You can gather information about hidden data by reading query
> plans.

I'm not convinced by this argument that covert channels are "out of
scope".  That would be a fine justification for, say, a thesis topic.
However, what we're talking about here is a real-world feature that will
be of no real-world use if it can't stand up against rather obvious attack
techniques.  I'm not interested in carrying the maintenance and runtime
overhead of a feature that's only of academic value.

			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: <4142.1377785114@sss.pgh.pa.us>
Permalink:  ../4142.1377785114@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/4142.1377785114@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, aekorotkov@gmail.com, kaigai@kaigai.gr.jp, obartunov@gmail.com, greg@2ndquadrant.com
  Subject: Re: [v9.4] row level security
  In-Reply-To: <4142.1377785114@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