I summarized the series of discussion at:
http://wiki.postgresql.org/wiki/RLS#Issue:_A_leaky_VIEWs_for_RLS
Please point out, if I missed or misunderstood something.
Thanks,
(2010/06/03 11:36), KaiGai Kohei wrote:
(2010/06/02 12:02), KaiGai Kohei wrote:
Here's another thought. If we're
(2010/06/02 12:02), KaiGai Kohei wrote:
Here's another thought. If we're leaning toward explicit syntax to
designate security views (and I do mean IF, since only one person has
signed on to that, even if it is Tom Lane!), then maybe we should
think about ripping out the logic that causes
As it was reported before, we have an open item about leaky VIEWs for RLS.
On the talk at Ottawa, Robert suggested me to post my idea prior to submit
a patch. So, I'd like to explain my idea at first.
Actually I'm not familiar to optimizar details, so it needs any helps from
experts of optimizar.
On 01/06/10 11:39, KaiGai Kohei wrote:
Any operators eventually invokes a function
being correctly installed, but an assumption is that we can trust operators,
index access method, type input/output methods, conversions and so on, because
these features have to be installed by DBA (or initdb).
(2010/06/01 18:08), Heikki Linnakangas wrote:
On 01/06/10 11:39, KaiGai Kohei wrote:
Any operators eventually invokes a function
being correctly installed, but an assumption is that we can trust operators,
index access method, type input/output methods, conversions and so on,
because
these
On 01/06/10 13:04, KaiGai Kohei wrote:
Oops, I missed it. Indeed, operator function is not limited to C-language
functions, so regular users can create it.
Apart from the topic, does it seem to you reasonable direction to tackle to
the leaky VIEWs problem?
Yeah, I guess it is.
The general
On Jun 1, 2010, at 10:39 , KaiGai Kohei wrote:
I have an idea that we add FuncExpr a new field (e.g nestlevel) to remember
where is originally put in the query, and prevent reordering over the nest
level of subqueries.
In above example, f_malicious() has nestlevel=0 because it is put on the
2010/6/1 KaiGai Kohei kai...@ak.jp.nec.com:
I have an idea that we add FuncExpr a new field (e.g nestlevel) to remember
where is originally put in the query, and prevent reordering over the nest
level of subqueries.
In above example, f_malicious() has nestlevel=0 because it is put on the top
2010/6/1 Heikki Linnakangas heikki.linnakan...@enterprisedb.com:
On 01/06/10 11:39, KaiGai Kohei wrote:
Any operators eventually invokes a function
being correctly installed, but an assumption is that we can trust operators,
index access method, type input/output methods, conversions and so
2010/6/1 Heikki Linnakangas heikki.linnakan...@enterprisedb.com:
The general problem is that it seems like a nightmare to maintain this
throughout the planner. Who knows what optimizations this affects, and
do we need to hide things like row-counts in EXPLAIN output? If we try
to be very
Greg Stark gsst...@mit.edu writes:
Heikki's point is still valid though. Consider if it's not a matter of
filter ordering but rather that a filter is being pushed down inside a
join. If the join is from the view then it would be unsafe to filter
the rows before seeing which rows match the
Also incidentally I'm having trouble imagining a scenario where this
really matters. For it to be an issue you would have to simultaneously
have a user which can't access all the data and must go through views
which limit the data he can access -- and has privileges to issue DDL
to create
* Greg Stark (gsst...@mit.edu) wrote:
Also incidentally I'm having trouble imagining a scenario where this
really matters. For it to be an issue you would have to simultaneously
have a user which can't access all the data and must go through views
which limit the data he can access -- and has
On Tue, Jun 1, 2010 at 10:57 AM, Tom Lane t...@sss.pgh.pa.us wrote:
CREATE SECURITY VIEW, anyone?
That may be the best approach, but I think it needs more than one line
of exposition. The approach I proposed was to test whether the user
has privileges to execute the underlying query directly
Robert Haas robertmh...@gmail.com writes:
On Tue, Jun 1, 2010 at 10:57 AM, Tom Lane t...@sss.pgh.pa.us wrote:
CREATE SECURITY VIEW, anyone?
That may be the best approach, but I think it needs more than one line
of exposition. The approach I proposed was to test whether the user
has
On Tue, Jun 1, 2010 at 1:02 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Jun 1, 2010 at 10:57 AM, Tom Lane t...@sss.pgh.pa.us wrote:
CREATE SECURITY VIEW, anyone?
That may be the best approach, but I think it needs more than one line
of exposition.
On Tue, Jun 1, 2010 at 1:28 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Jun 1, 2010 at 1:02 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Jun 1, 2010 at 10:57 AM, Tom Lane t...@sss.pgh.pa.us wrote:
CREATE SECURITY VIEW, anyone?
That may be
On Tue, Jun 1, 2010 at 4:10 PM, Merlin Moncure mmonc...@gmail.com wrote:
On Tue, Jun 1, 2010 at 1:28 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Jun 1, 2010 at 1:02 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Jun 1, 2010 at 10:57 AM, Tom
On Tue, Jun 1, 2010 at 4:57 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Jun 1, 2010 at 4:10 PM, Merlin Moncure mmonc...@gmail.com wrote:
have you ruled out: 'create function'? :-)
You lost me...
Well, as noted by the OP, using views for security in postgres is
simply wishful
(2010/06/01 22:16), Robert Haas wrote:
2010/6/1 Heikki Linnakangasheikki.linnakan...@enterprisedb.com:
The general problem is that it seems like a nightmare to maintain this
throughout the planner. Who knows what optimizations this affects, and
do we need to hide things like row-counts in
(2010/06/01 22:09), Robert Haas wrote:
2010/6/1 KaiGai Koheikai...@ak.jp.nec.com:
I have an idea that we add FuncExpr a new field (e.g nestlevel) to remember
where is originally put in the query, and prevent reordering over the nest
level of subqueries.
In above example, f_malicious() has
(2010/06/02 2:28), Robert Haas wrote:
On Tue, Jun 1, 2010 at 1:02 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Robert Haasrobertmh...@gmail.com writes:
On Tue, Jun 1, 2010 at 10:57 AM, Tom Lanet...@sss.pgh.pa.us wrote:
CREATE SECURITY VIEW, anyone?
That may be the best approach, but I think it
2010/6/1 KaiGai Kohei kai...@ak.jp.nec.com:
Eh, if that's the consensus, it doesn't bother me that much, but it
doesn't really answer the question, either: supposing we add an
explicit concept of a security view, what should its semantics be?
How about a GUC option to provide the default,
(2010/06/02 10:52), Robert Haas wrote:
2010/6/1 KaiGai Koheikai...@ak.jp.nec.com:
Eh, if that's the consensus, it doesn't bother me that much, but it
doesn't really answer the question, either: supposing we add an
explicit concept of a security view, what should its semantics be?
How about a
24 matches
Mail list logo
