DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=ymail.com;
 h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding;
 b=Vcnd01T1FPcdEFJzRjO/9VeiKjWgO6oUtXAPwEaXH0pKmS/HqdrwkrbTpH5GCL/TOzE8I/4X3dmcHBAqR0v5Le+IRq8oS+Tn6xwp8YJmGPuNY+FVbG1PigHi19dmCNA6fljDOM2AlKpb8l7071WnQvwcQqLN/zEEADCvib1EUas=;
References: 
 <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>
	<CADyhKSW_o2nVWFytdTY84DUXZSuZkD_EtY2d8wAjR18UruOXYQ@mail.gmail.com>
	<WM!fb94ecb91cd381e69d8e4773d3810f48e4e0ef000525cc806c4ee509f215ce1a39c8c2a1c3ffde72ba2ddb1a07ebcdc9!@asav-2.01.com>
	<5220D832.7090104@agliodbs.com>	<20130830192729.GO2706@tamriel.snowman.net>
	<16798.1377891794@sss.pgh.pa.us>
	<CA+TgmoZYv_me1iB6iDRA_oO-o9xkxXYqr-0UtwK5itpZbDsqYA@mail.gmail.com>
	<1398.1378305956@sss.pgh.pa.us>
	<CA+TgmoYTf+4RUOW8stVz1RE+3TD+QR5TNKzYuFDCehSkieL5OQ@mail.gmail.com>
	<1543.1378306249@sss.pgh.pa.us>
 <CA+TgmobRiYj8NCb4Lra5-MzvjnVKz6OrYSsn-Z04YJGsmiQAsg@mail.gmail.com>
Message-ID: <1378308251.45837.YahooMailNeo@web162905.mail.bf1.yahoo.com>
Date: Wed, 4 Sep 2013 08:24:11 -0700 (PDT)
From: Kevin Grittner <kgrittn@ymail.com>
Reply-To: Kevin Grittner <kgrittn@ymail.com>
Subject: Re: [v9.4] row level security
To: Robert Haas <robertmhaas@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>
Cc: Stephen Frost <sfrost@snowman.net>, Josh Berkus <josh@agliodbs.com>,
 Kohei KaiGai <kaigai@kaigai.gr.jp>, "ktm@rice.edu" <ktm@rice.edu>,
 Alexander Korotkov <aekorotkov@gmail.com>,
 Oleg Bartunov <obartunov@gmail.com>, Greg Smith <greg@2ndquadrant.com>,
 PgHacker <pgsql-hackers@postgresql.org>
In-Reply-To: 
 <CA+TgmobRiYj8NCb4Lra5-MzvjnVKz6OrYSsn-Z04YJGsmiQAsg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

Robert Haas <robertmhaas@gmail.com> wrote:
> Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Robert Haas <robertmhaas@gmail.com> writes:

>>> IMHO, this new feature should be similarly simple: when an
>>> unprivileged user references a table, treat that as a reference
>>> to a leakproof view over the table, with the RLS qual injected
>>> into the view.
>>
>> And for insert/update/delete, we do what exactly?
>
> The same mechanism will prevent UPDATE and DELETE from seeing any
> rows the user shouldn't be able to touch.

+1

> Simon and Greg are arguing that when an INSERT or UPDATE happens,
> we ought to also check that the NEW row matches the RLS qual.=A0 I
> don't find that to be terribly important because you can
> accomplish the same thing with a per-row trigger today; and I
> also don't think everyone will want that behavior.

As an example from my Wisconsin Courts days, source documents come
in which need to be entered, which may contain a Social Security
Number, and most of the Clerk of Courts staff should be authorized
to enter that into the database.=A0 Once it is entered, most people
should not be allowed to view it, including many of the people who
were authorized to enter it initially.=A0 It's one thing for a line
staff person to have a handful of documents come across their desk
with SSN on a given day; it's quite another if they could dump a
list of names, addresses, dates of birth, and SSNs for the entire
database on demand.

In a way this issue is similar to the covert channel issue --
volume matters.

--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


--=20
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers