From: Stephen Frost <sfrost@snowman.net>
To: KaiGai Kohei <kaigai@ak.jp.nec.com>
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: Mon, 14 Dec 2009 21:06:52 -0500
Message-ID: <20091215020652.GV17756@tamriel.snowman.net> (raw)
In-Reply-To: <4B26E910.4060604@ak.jp.nec.com>
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>
KaiGai,
* KaiGai Kohei (kaigai@ak.jp.nec.com) wrote:
> 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.
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 = 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
Attachments:
[application/pgp-signature] signature.asc (196B, ../20091215020652.GV17756@tamriel.snowman.net/2-signature.asc)
download
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: sfrost@snowman.net, kaigai@ak.jp.nec.com, kaigai@kaigai.gr.jp, robertmhaas@gmail.com, josh@agliodbs.com
Subject: Re: Row-Level Security
In-Reply-To: <20091215020652.GV17756@tamriel.snowman.net>
* 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