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 l
(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 caus
(2010/06/02 10:52), Robert Haas wrote:
> 2010/6/1 KaiGai Kohei:
>>> 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 op
2010/6/1 KaiGai Kohei :
>> 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, like default_wit
(2010/06/02 2:28), Robert Haas wrote:
> On Tue, Jun 1, 2010 at 1:02 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> On Tue, Jun 1, 2010 at 10:57 AM, Tom Lane wrote:
CREATE SECURITY VIEW, anyone?
>>
>>> That may be the best approach, but I think it needs more than one line
>>> of exposition.
(2010/06/01 22:09), Robert Haas wrote:
> 2010/6/1 KaiGai Kohei:
>> 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 bec
(2010/06/01 22:16), Robert Haas wrote:
> 2010/6/1 Heikki Linnakangas:
>> 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 b
On Tue, Jun 1, 2010 at 4:57 PM, Robert Haas wrote:
> On Tue, Jun 1, 2010 at 4:10 PM, Merlin Moncure 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 thinking. This is part of a family of issu
On Tue, Jun 1, 2010 at 4:10 PM, Merlin Moncure wrote:
> On Tue, Jun 1, 2010 at 1:28 PM, Robert Haas wrote:
>> On Tue, Jun 1, 2010 at 1:02 PM, Tom Lane wrote:
>>> Robert Haas writes:
On Tue, Jun 1, 2010 at 10:57 AM, Tom Lane wrote:
> CREATE SECURITY VIEW, anyone?
>>>
That may be t
On Tue, Jun 1, 2010 at 1:28 PM, Robert Haas wrote:
> On Tue, Jun 1, 2010 at 1:02 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> On Tue, Jun 1, 2010 at 10:57 AM, Tom Lane wrote:
CREATE SECURITY VIEW, anyone?
>>
>>> That may be the best approach, but I think it needs more than one line
>>> o
On Tue, Jun 1, 2010 at 1:02 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Jun 1, 2010 at 10:57 AM, Tom Lane 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 t
Robert Haas writes:
> On Tue, Jun 1, 2010 at 10:57 AM, Tom Lane 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
On Tue, Jun 1, 2010 at 10:57 AM, Tom Lane 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 without going
throug
* 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 h
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 functions
Greg Stark 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 join... unless w
2010/6/1 Heikki Linnakangas :
> 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 strict, we can expect a stream of CVE
2010/6/1 Heikki Linnakangas :
> 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 featur
2010/6/1 KaiGai Kohei :
> 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
> level.
> But f_p
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
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 gene
(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
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 initd
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.
24 matches
Mail list logo
