Date: Mon, 14 Dec 2009 21:06:52 -0500
From: Stephen Frost <sfrost@snowman.net>
To: KaiGai Kohei <kaigai@ak.jp.nec.com>
Cc: KaiGai Kohei <kaigai@kaigai.gr.jp>, Robert Haas <robertmhaas@gmail.com>,
	Josh Berkus <josh@agliodbs.com>, pgsql-hackers@postgresql.org
Subject: Re: Row-Level Security
Message-ID: <20091215020652.GV17756@tamriel.snowman.net>
References: <603c8f070912121918i59f807e3n5ed4d4699227e43@mail.gmail.com>
	<4B24AAED.2080706@kaigai.gr.jp>
	<603c8f070912130411q765c7e9aw371b468229b8e32@mail.gmail.com>
	<4B25C5B2.9010108@ak.jp.nec.com>
	<603c8f070912132135l43bdf060sa5207b5a4d2c918c@mail.gmail.com>
	<4B25DE99.2050801@ak.jp.nec.com>
	<603c8f070912140318i6bbc1d63o9e81d409d0b342b6@mail.gmail.com>
	<4B2626ED.7030104@kaigai.gr.jp>
	<20091214134714.GS17756@tamriel.snowman.net>
	<4B26E910.4060604@ak.jp.nec.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="aKhK6dkhGyG6M3qJ"
Content-Disposition: inline
In-Reply-To: <4B26E910.4060604@ak.jp.nec.com>
User-Agent: Mutt/1.5.18 (2008-05-17)


--aKhK6dkhGyG6M3qJ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

KaiGai,

* KaiGai Kohei (kaigai@ak.jp.nec.com) wrote:
> IIRC, one headache issue is that user may provide well indexable conditio=
ns,
> such as "SELECT * FROM view_x WHERE id =3D 1234". In this case, if we str=
ictly
> keep the order of evaluation between inside and outside of the view, its
> performance penalty will over reasonable tradeoff to the better security.
>=20
> Someone pointed out user given conditions which can be replaced by index =
scan
> are "trusted", so all we need to focus on are conditions which need to ch=
eck
> for each tuples. I also think it is a right direction, as long as we can
> restrict who can define index access method in appropriate way.

It sounds like that might help, but I feel that a whole solution will be
more complex than just differentiating between seq scan nodes and index
scan ones.

> If we can focus on the order of evaluation on the non-indexed conditions,
> the point is order_qual_clauses() which sort the given qual list based on
> the cost evaluation. If we can mark condition node a flag which means this
> node come from inside of view or row-level policy, it is not difficult to
> keep evaluation order.

Identifying where this matters is important.  Anyone have suggestions on
how to do that?  There was some discussion on IRC about that but it
didn't really go anywhere.  I don't like the idea of presuming the user
will always want to limit the planner in this way.  Perhaps we can
convince ourselves, once we have an implementation, that it doesn't
poorly affect performance (the primary reason to avoid constraining the
planner), or that it's what our users would really want (I might be able
to buy off on this..), but I doubt it.

A couple of options about how the user could ask us to constrain the
planning to eliminate this issue are, off-hand:
Global GUC which enables/disables
Attribute of the view, perhaps indicated as 'CREATE SECURITY VIEW' or
similar
Something in the definition of the WHERE clause, eg: select * from x
where security(q =3D 50);

Anyone have thoughts about this?  Perhaps it's too early to discuss
this anyway, just trying to keep the discussion moving in some way.

> However, it is just my quick idea. It might miss something.
> We need to consider the matter for more details...

I agree, this needs more thought and input from others who are very
familiar with the planner, executor, etc.  Additionally, this needs
to be done before we can really go anywhere with row-level security.

	Thanks,

		Stephen

--aKhK6dkhGyG6M3qJ
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAksm7zwACgkQrzgMPqB3kigG8ACaArGuetmzxqEBYeqO/BL4knfE
qIQAn2n6PscYEDHOIGYA5rJsjckhLkjG
=H4o7
-----END PGP SIGNATURE-----

--aKhK6dkhGyG6M3qJ--