Received: from makus.postgresql.org ([98.129.198.125])
	by malur.postgresql.org with esmtp (Exim 4.72)
	(envelope-from <tgl@sss.pgh.pa.us>) id 1TQKh9-0005y1-0K
	for pgsql-hackers@postgresql.org; Mon, 22 Oct 2012 16:17:39 +0000
Received: from sss.pgh.pa.us ([66.207.139.130])
	by makus.postgresql.org with esmtp (Exim 4.72)
	(envelope-from <tgl@sss.pgh.pa.us>) id 1TQKh7-00023D-Tx
	for pgsql-hackers@postgresql.org; Mon, 22 Oct 2012 16:17:38 +0000
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
	by sss.pgh.pa.us (8.14.5/8.14.5) with ESMTP id q9MGHXUS002994;
	Mon, 22 Oct 2012 12:17:33 -0400 (EDT)
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
cc: Alvaro Herrera <alvherre@2ndquadrant.com>,
	Kohei KaiGai <kaigai@kaigai.gr.jp>,
	Dean Rasheed <dean.a.rasheed@gmail.com>, Florian Pflug <fgp@phlo.org>,
	PgHacker <pgsql-hackers@postgresql.org>
Subject: Re: [v9.3] Row-Level Security
In-reply-to: 
 <CA+TgmoY6m-HCQfX8Qz8V5c9wbzqFU7GSpWaBDLcpb4o2sWtcEQ@mail.gmail.com>
References: 
 <CADyhKSUXVffLJrmfMpi2xH=U+bFxu9Qa4w7kVhQoxkMfQOJ3yw@mail.gmail.com>
	<CA+TgmoZE3cD4-cWDK8M+UoiMQhoyzyp7s4xvbxgqFk2Su_G0yg@mail.gmail.com>
	<CADyhKSWB=evF9AnB683fNxfD8H80d6nzLcx6O81jewfnUwEeJw@mail.gmail.com>
	<CAEZATCVKpJmf7BDQps8rzwgo0k9Ei6u9i12RaLX-s8bEEY+eAw@mail.gmail.com>
	<CADyhKSWcd6i5c30-AzSZ1RSge4s7vw+nahi36Vf2g_UkwuA4sA@mail.gmail.com>
	<CADyhKSUEGdMeWKtAP6oFzn6e8QK9zFmhdqdpB_GF7O=sdADvAQ@mail.gmail.com>
	<CADyhKSU+Qwx6qkeELr=MbZ7Lz2Wpoqn9Uihff-OktJ_wogHEpw@mail.gmail.com>
	<CAEZATCUz7+QVudWbgnSrv-KbHRPq33Z07vdv1eYn+cDRMbazzQ@mail.gmail.com>
	<CADyhKSXHQxKYpnm4VizVnh=6Gv-TnxbjnucjWaH1am8zpvXY0Q@mail.gmail.com>
	<CADyhKSUFcMcwup1=ydvwghiy21Vn_OGzO-rX-VCBO1CSDNNTMQ@mail.gmail.com>
	<20121018181956.GL3763@alvh.no-ip.org>
	<CA+TgmoY6m-HCQfX8Qz8V5c9wbzqFU7GSpWaBDLcpb4o2sWtcEQ@mail.gmail.com>
Comments: In-reply-to Robert Haas <robertmhaas@gmail.com>
	message dated "Mon, 22 Oct 2012 09:33:58 -0400"
Date: Mon, 22 Oct 2012 12:17:33 -0400
Message-ID: <2993.1350922653@sss.pgh.pa.us>
X-Pg-Spam-Score: -2.6 (--)
X-Archive-Number: 201210/1309
X-Sequence-Number: 215545

Robert Haas <robertmhaas@gmail.com> writes:
> The documentation lists several documented limitations that I would
> like to analyze a little bit.  First, it says that row-level security
> policies are not applied on UPDATE or DELETE.  That sounds downright
> dangerous to me.  Is there some really compelling reason we're not
> doing it?

[ blink... ]  Isn't that a security hole big enough for a Mack truck?

	UPDATE tab SET foo = foo RETURNING *;

sucks out all the data just fine, if RLS doesn't apply to it.

Having said that, I fear that sensible row-level security for updates is
at least one order of magnitude harder than sensible row-level security
for selects.  We've speculated about how to define that in the past,
IIRC, but without any very satisfactory outcome.

			regards, tom lane