From: KaiGai Kohei <kaigai@ak.jp.nec.com>
To: Stephen Frost <sfrost@snowman.net>
Cc: KaiGai Kohei <kaigai@kaigai.gr.jp>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Josh Berkus <josh@agliodbs.com>
Cc: pgsql-hackers@postgresql.org
Subject: Re: Row-Level Security
Date: Tue, 15 Dec 2009 10:40:32 +0900
Message-ID: <4B26E910.4060604@ak.jp.nec.com> (raw)
In-Reply-To: <20091214134714.GS17756@tamriel.snowman.net>
References: <20091212203003.GL17756@tamriel.snowman.net>
<4B24381F.7050407@agliodbs.com>
<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>
Stephen Frost wrote:
> KaiGai,
>
> * KaiGai Kohei (kaigai@kaigai.gr.jp) wrote:
>> The reason why I put on the security hook in ExecScan() is to avoid the
>> problem that row-cost user defined function can be evaluated earlier
>> than row-level security policy. (I believed it was a well-known problem
>> at that time yet.) So, I didn't want to append it before optimization.
>
> This is a problem which needs to be addressed and fixed independently.
>
>> I also believe this matter should be resolved when we provide row-level
>> security stuff, because it is a security feature.
>
> This issue should be fixed first, not as part of some large-scale patch.
>
> If you have thoughts or ideas about how to address this problem as it
> relates to views, I think you would find alot of people willing to
> listen and to discuss it. This must be independent of SELinux,
> independent of row-level security, and isn't something based on any of
> the patches which have been submitted so far. None of them that I've
> seen resolve this problem in a way that the community is willing to
> accept.
Sorry, I don't have something good idea at the moment.
IIRC, one headache issue is that user may provide well indexable conditions,
such as "SELECT * FROM view_x WHERE id = 1234". In this case, if we strictly
keep the order of evaluation between inside and outside of the view, its
performance penalty will over reasonable tradeoff to the better security.
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 check
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.
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.
However, it is just my quick idea. It might miss something.
We need to consider the matter for more details...
--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>
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: kaigai@ak.jp.nec.com, sfrost@snowman.net, kaigai@kaigai.gr.jp, robertmhaas@gmail.com, josh@agliodbs.com
Subject: Re: Row-Level Security
In-Reply-To: <4B26E910.4060604@ak.jp.nec.com>
* 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