From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alexander Korotkov <aekorotkov@gmail.com>
cc: Kohei KaiGai <kaigai@kaigai.gr.jp>, Oleg Bartunov <obartunov@gmail.com>,
 Greg Smith <greg@2ndquadrant.com>, PgHacker <pgsql-hackers@postgresql.org>
Subject: Re: [v9.4] row level security
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>
Comments: In-reply-to Alexander Korotkov <aekorotkov@gmail.com>
 message dated "Thu, 29 Aug 2013 16:09:35 +0400"
Date: Thu, 29 Aug 2013 10:05:14 -0400
Message-ID: <4142.1377785114@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

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