Sorry for my late reply.
2012/6/6 Florian Pflug :
> On Jun5, 2012, at 22:33 , Kohei KaiGai wrote:
>> 2012/6/5 Florian Pflug :
>>> I can live with any behaviour, as long as it doesn't depends on details
>>> of the query plan. My vote would be for always using the role which was
>>> active at statem
On Jun5, 2012, at 22:33 , Kohei KaiGai wrote:
> 2012/6/5 Florian Pflug :
>> I can live with any behaviour, as long as it doesn't depends on details
>> of the query plan. My vote would be for always using the role which was
>> active at statement creation time (i.e. at PREPARE/DECLARE time) for
>> R
2012/6/5 Florian Pflug :
> On Jun5, 2012, at 15:07 , Kohei KaiGai wrote:
>> 2012/6/5 Florian Pflug :
>>> On Jun5, 2012, at 11:43 , Kohei KaiGai wrote:
I think it does not require to add a mechanism to invalidate
prepared-statement, because all the checks are applied on
executor stage
On Jun5, 2012, at 15:07 , Kohei KaiGai wrote:
> 2012/6/5 Florian Pflug :
>> On Jun5, 2012, at 11:43 , Kohei KaiGai wrote:
>>> I think it does not require to add a mechanism to invalidate
>>> prepared-statement, because all the checks are applied on
>>> executor stage. And these functions can be sta
2012/6/5 Florian Pflug :
> On Jun5, 2012, at 11:43 , Kohei KaiGai wrote:
>> 2012/6/5 Florian Pflug :
>>> What's to be gained by that? Once there's *any* way to bypass a RLS
>>> policy, you'll have to deal with the plan invalidation issues you
>>> mentioned anyway. ISTM that complexity-wide, you don
On Jun5, 2012, at 11:43 , Kohei KaiGai wrote:
> 2012/6/5 Florian Pflug :
>> What's to be gained by that? Once there's *any* way to bypass a RLS
>> policy, you'll have to deal with the plan invalidation issues you
>> mentioned anyway. ISTM that complexity-wide, you don't save much by not
>> having R
2012/6/5 Florian Pflug :
> On Jun5, 2012, at 10:22 , Kohei KaiGai wrote:
>> 2012/6/5 Tom Lane :
>>> I suspect that KaiGai-san's objection basically comes down to not
>>> wanting to have what amounts to a backdoor in RLS policies. However,
>>> what Florian is saying is that you have to have a backd
On Jun5, 2012, at 10:22 , Kohei KaiGai wrote:
> 2012/6/5 Tom Lane :
>> I suspect that KaiGai-san's objection basically comes down to not
>> wanting to have what amounts to a backdoor in RLS policies. However,
>> what Florian is saying is that you have to have a backdoor anyway,
>> unless you'd lik
2012/6/5 Tom Lane :
> Florian Pflug writes:
>> On Jun4, 2012, at 18:38 , Kohei KaiGai wrote:
>>> 2012/6/4 Florian Pflug :
Without something like RLSBYPASS, the DBA needs to have intimate
knowledge about the different RLS policies to e.g. guarantee that his
backups aren't missing cru
Florian Pflug writes:
> On Jun4, 2012, at 18:38 , Kohei KaiGai wrote:
>> 2012/6/4 Florian Pflug :
>>> Without something like RLSBYPASS, the DBA needs to have intimate
>>> knowledge about the different RLS policies to e.g. guarantee that his
>>> backups aren't missing crucial information, or that t
On Jun4, 2012, at 18:38 , Kohei KaiGai wrote:
> 2012/6/4 Florian Pflug :
>> Without something like RLSBYPASS, the DBA needs to have intimate
>> knowledge about the different RLS policies to e.g. guarantee that his
>> backups aren't missing crucial information, or that the replication
>> system inde
2012/6/4 Tom Lane :
> Kohei KaiGai writes:
>> Here is two problems around RLSBYPASS. The first is we have
>> no idea to handle invalidation of prepared-statement when current
>> user is switched, right now.
>
> How is that specifically the fault of RLSBYPASS? *Any* of the schemes
> you're proposi
Kohei KaiGai writes:
> Here is two problems around RLSBYPASS. The first is we have
> no idea to handle invalidation of prepared-statement when current
> user is switched, right now.
How is that specifically the fault of RLSBYPASS? *Any* of the schemes
you're proposing for inlined RLS checks will
2012/6/4 Florian Pflug :
> On Jun4, 2012, at 17:38 , Kohei KaiGai wrote:
>> I'm worry about future maintenance issues, once we have
>> RLSBYPASS permission or something user visible…
>
> I fear that without a generic way to disable RLS regardless which
> RLS policy function is in effect, we're crea
On Jun4, 2012, at 17:38 , Kohei KaiGai wrote:
> I'm worry about future maintenance issues, once we have
> RLSBYPASS permission or something user visible…
I fear that without a generic way to disable RLS regardless which
RLS policy function is in effect, we're creating a huge maintenance
issue for
2012/6/4 Robert Haas :
> On Sat, Jun 2, 2012 at 12:58 AM, Kohei KaiGai wrote:
>> 2012/6/1 Robert Haas :
>>> On Thu, May 31, 2012 at 3:52 PM, Kohei KaiGai wrote:
It may be an option to separate the case into two; a situation to execute
the given query immediately just after optimization
On Sat, Jun 2, 2012 at 12:58 AM, Kohei KaiGai wrote:
> 2012/6/1 Robert Haas :
>> On Thu, May 31, 2012 at 3:52 PM, Kohei KaiGai wrote:
>>> It may be an option to separate the case into two; a situation to execute
>>> the given query immediately just after optimization and never reused,
>>> and oth
2012/6/1 Robert Haas :
> On Thu, May 31, 2012 at 3:52 PM, Kohei KaiGai wrote:
>> It may be an option to separate the case into two; a situation to execute
>> the given query immediately just after optimization and never reused,
>> and others.
>
> Yes. Simon suggested exactly this a while back, an
On Thu, May 31, 2012 at 3:52 PM, Kohei KaiGai wrote:
> It may be an option to separate the case into two; a situation to execute
> the given query immediately just after optimization and never reused,
> and others.
Yes. Simon suggested exactly this a while back, and I agree with him
that we ough
2012/5/31 Kohei KaiGai :
> 2012/5/31 Robert Haas :
>>> If we would have an "ideal optimizer", I'd still like the optimizer to
>>> wipe out redundant clauses transparently, rather than RLSBYPASS
>>> permissions, because it just controls all-or-nothing stuff.
>>> For example, if tuples are categorize
2012/5/31 Robert Haas :
>> If we would have an "ideal optimizer", I'd still like the optimizer to
>> wipe out redundant clauses transparently, rather than RLSBYPASS
>> permissions, because it just controls all-or-nothing stuff.
>> For example, if tuples are categorized to unclassified, classified o
On Wed, May 30, 2012 at 3:26 PM, Kohei KaiGai wrote:
> My preference is RLSBYPASS permission rather than the approach
> with functions that return policy clause at run-time, because it needs
> to invalidate prepared statement at random timing.
> In case of this function approach, the RLS policy sh
2012/5/31 Yeb Havinga :
> On 2012-05-30 21:26, Kohei KaiGai wrote:
>>
>> If we would have an "ideal optimizer", I'd still like the optimizer to
>> wipe out redundant clauses transparently, rather than RLSBYPASS
>> permissions, because it just controls all-or-nothing stuff.
>> For example, if tuples
On 2012-05-30 21:26, Kohei KaiGai wrote:
If we would have an "ideal optimizer", I'd still like the optimizer to
wipe out redundant clauses transparently, rather than RLSBYPASS
permissions, because it just controls all-or-nothing stuff.
For example, if tuples are categorized to unclassified, class
2012/5/29 Robert Haas :
> On Fri, May 25, 2012 at 5:08 PM, Kohei KaiGai wrote:
I think it is a good idea not to apply RLS when current user has
superuser privilege from perspective of security model consistency,
but it is inconsistent to check privileges underlying tables.
>>>
>>> S
On May29, 2012, at 16:57 , Kohei KaiGai wrote:
> 2012/5/29 Robert Haas :
>> One idea might be to have a grantable permission that permits the RLS
>> policy to be bypassed. So, if a user has only SELECT permission, they
>> can select from the table, but the RLS policy will apply. If they
>> have b
On Tue, May 29, 2012 at 10:57 AM, Kohei KaiGai wrote:
> 2012/5/29 Robert Haas :
>> One idea might be to have a grantable permission that permits the RLS
>> policy to be bypassed. So, if a user has only SELECT permission, they
>> can select from the table, but the RLS policy will apply. If they
>
On Fri, May 25, 2012 at 5:08 PM, Kohei KaiGai wrote:
>>> I think it is a good idea not to apply RLS when current user has
>>> superuser privilege from perspective of security model consistency,
>>> but it is inconsistent to check privileges underlying tables.
>>
>> Seems like a somewhat random war
2012/5/29 Robert Haas :
> One idea might be to have a grantable permission that permits the RLS
> policy to be bypassed. So, if a user has only SELECT permission, they
> can select from the table, but the RLS policy will apply. If they
> have both SELECT and RLSBYPASS (probably not what we really
On May29, 2012, at 16:34 , Robert Haas wrote:
> One idea might be to have a grantable permission that permits the RLS
> policy to be bypassed. So, if a user has only SELECT permission, they
> can select from the table, but the RLS policy will apply. If they
> have both SELECT and RLSBYPASS (proba
On Tue, May 29, 2012 at 9:12 AM, Florian Pflug wrote:
> On May29, 2012, at 13:37 , Kohei KaiGai wrote:
>> 2012/5/27 Alastair Turner :
>>> Excerpts from Kohei KaiGai wrote on Fri, May 25,
>>> 2012 at 11:08 PM:
If we assume RLS is applied when user has
no privileges on tables, the current
2012/5/29 Florian Pflug :
> On May29, 2012, at 13:37 , Kohei KaiGai wrote:
>> 2012/5/27 Alastair Turner :
>>> Excerpts from Kohei KaiGai wrote on Fri, May 25,
>>> 2012 at 11:08 PM:
If we assume RLS is applied when user has
no privileges on tables, the current ExecCheckRTEPerms()
alw
On May29, 2012, at 16:13 , Kohei KaiGai wrote:
> 2012/5/29 Florian Pflug :
>> My motivation for suggesting that flag was to prevent people who want RLS,
>> yet aren't concerned about leaks, from having to pay the performance penalty
>> associated with not pushing down predicates.
>>
> I think it i
2012/5/29 Florian Pflug :
> On May29, 2012, at 13:59 , Kohei KaiGai wrote:
>> 2012/5/28 Florian Pflug :
>>> Concept B is handled adequately by the LEAKPROOF flag. Concept C is handled
>>> by the security_barrier flag. However, as you pointed out, it's a bit of a
>>> dubious concept and only really
On May29, 2012, at 13:37 , Kohei KaiGai wrote:
> 2012/5/27 Alastair Turner :
>> Excerpts from Kohei KaiGai wrote on Fri, May 25,
>> 2012 at 11:08 PM:
>>> If we assume RLS is applied when user has
>>> no privileges on tables, the current ExecCheckRTEPerms()
>>> always raises an error towards unpriv
On May29, 2012, at 13:59 , Kohei KaiGai wrote:
> 2012/5/28 Florian Pflug :
>> Concept B is handled adequately by the LEAKPROOF flag. Concept C is handled
>> by the security_barrier flag. However, as you pointed out, it's a bit of a
>> dubious concept and only really necessary for backwards compatib
2012/5/28 Florian Pflug :
> On May28, 2012, at 02:46 , Noah Misch wrote:
>> On Thu, May 24, 2012 at 07:31:37PM +0200, Florian Pflug wrote:
>>> Since the security barrier flag carries a potentially hefty performance
>>> penalty, I think it should be optional. Application which don't allow
>>> SQL-le
2012/5/27 Alastair Turner :
> Excerpts from Kohei KaiGai wrote on Fri, May 25,
> 2012 at 11:08 PM:
>> If we assume RLS is applied when user has
>> no privileges on tables, the current ExecCheckRTEPerms()
>> always raises an error towards unprivileged users, prior to
>> execution of queries.
>> Isn
On May25, 2012, at 23:32 , Kohei KaiGai wrote:
> However, it should not be applied on triggers being set on PK tables,
> because it allows to modify or delete primary-key being referenced by
> invisible foreign-key from the viewpoint of operators.
> I think, it makes sense to have exceptional cases
On May28, 2012, at 02:46 , Noah Misch wrote:
> On Thu, May 24, 2012 at 07:31:37PM +0200, Florian Pflug wrote:
>> Since the security barrier flag carries a potentially hefty performance
>> penalty, I think it should be optional. Application which don't allow
>> SQL-level access to the database might
On Thu, May 24, 2012 at 07:31:37PM +0200, Florian Pflug wrote:
> On May24, 2012, at 18:42 , Kohei KaiGai wrote:
> > As we discussed, it causes a problem with approach to append
> > additional qualifiers to where clause implicitly, because it does
> > not solve the matter corresponding to the order
Excerpts from Kohei KaiGai wrote on Fri, May 25,
2012 at 11:08 PM:
> If we assume RLS is applied when user has
> no privileges on tables, the current ExecCheckRTEPerms()
> always raises an error towards unprivileged users, prior to
> execution of queries.
> Isn't it preferable behavior to allow un
2012/5/25 Florian Pflug :
> On May24, 2012, at 19:25 , Robert Haas wrote:
>> FWIW, I'm inclined to think that you should NOT be able to create a
>> row that references an invisible row. You might end up with that
>> situation anyway, because we don't know what the semantics of the
>> security poli
2012/5/24 Robert Haas :
> On Thu, May 24, 2012 at 12:00 PM, Kohei KaiGai wrote:
>>> Another issue, BTW, are FOREIGN KEY constraints. Should you be allowed to
>>> created references to rows which are invisible to you, or should FOREIGN KEY
>>> constraints be exempt from security policies? I'd say t
2012/5/24 Robert Haas :
> On Thu, May 24, 2012 at 6:11 AM, Kohei KaiGai wrote:
>>> Perhaps when we see that RLS
>>> applies, we should replace the reference to the original table with a
>>> subquery RTE that has the security_barrier flag set - essentially
>>> treating a table with RLS as if it wer
On May24, 2012, at 19:25 , Robert Haas wrote:
> FWIW, I'm inclined to think that you should NOT be able to create a
> row that references an invisible row. You might end up with that
> situation anyway, because we don't know what the semantics of the
> security policy are: rows might become visibl
On May24, 2012, at 18:42 , Kohei KaiGai wrote:
> I'd like to summarize the current design being discussed.
>
> syntax:
> ALTER TABLE WITH ROW LEVEL SECURITY
> ( ) [FOR (SELECT | UPDATE | DELETE)];
> ALTER TABLE WITHOUT ROW LEVEL SECURITY;
>
> I tried to patch the parser/gram.y, but here
On Thu, May 24, 2012 at 12:00 PM, Kohei KaiGai wrote:
>> Another issue, BTW, are FOREIGN KEY constraints. Should you be allowed to
>> created references to rows which are invisible to you, or should FOREIGN KEY
>> constraints be exempt from security policies? I'd say they shouldn't be, i.e.
>> the
On Thu, May 24, 2012 at 6:20 AM, Florian Pflug wrote:
> But the security policy should still apply to the old rows, i.e.
> you shouldn't be after to UPDATE or DELETE rows you cannot see, no?
Agreed.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
On Thu, May 24, 2012 at 6:11 AM, Kohei KaiGai wrote:
>> Perhaps when we see that RLS
>> applies, we should replace the reference to the original table with a
>> subquery RTE that has the security_barrier flag set - essentially
>> treating a table with RLS as if it were a security view.
>>
> I beco
I'd like to summarize the current design being discussed.
syntax:
ALTER TABLE WITH ROW LEVEL SECURITY
( ) [FOR (SELECT | UPDATE | DELETE)];
ALTER TABLE WITHOUT ROW LEVEL SECURITY;
I tried to patch the parser/gram.y, but here was syntax conflicts
on ADD / DROP sub-command.
And, I noti
2012/5/24 Florian Pflug :
> On May24, 2012, at 16:19 , Kohei KaiGai wrote:
>> So, the proposed interface might be revised as follows:
>> ALTER TABLE ADD SECURITY POLICY
>> (, ...) [FOR SELECT |
>> INSERT |
>>
On May24, 2012, at 16:19 , Kohei KaiGai wrote:
> So, the proposed interface might be revised as follows:
> ALTER TABLE ADD SECURITY POLICY
> (, ...) [FOR SELECT |
> INSERT |
> [BEF
2012/5/24 Florian Pflug :
> On May24, 2012, at 12:43 , Kohei KaiGai wrote:
>> The case of INSERT / DELETE are simple; All we need to apply is
>> checks on either new or old tuples.
>>
>> In case of UPDATE, we need to check on the old tuple whether use can
>> see, and on the new tuple whether use ca
On May24, 2012, at 12:43 , Kohei KaiGai wrote:
> The case of INSERT / DELETE are simple; All we need to apply is
> checks on either new or old tuples.
>
> In case of UPDATE, we need to check on the old tuple whether use can
> see, and on the new tuple whether use can store them.
> Indeed, these ar
2012/5/24 Florian Pflug :
>>> If we also apply the security policy to newer version of tuples on
>>> update and insert, one idea is to inject a before-row-(update|insert)
>>> trigger to check whether it satisfies the security policy.
>>> For same reason, the trigger should be executed at the end of
On May23, 2012, at 22:12 , Robert Haas wrote:
> Also, suppose that Bob applies an RLS policy to a table, and, later,
> Alice selects from the table. How do we keep Bob from usurping
> Alice's privileges?
That problem isn't restricted to RLW, though. Bob could just as well
have booby-trapped any o
2012/5/23 Robert Haas :
> On Wed, May 23, 2012 at 3:45 PM, Kohei KaiGai wrote:
>> I wanted to have discussion to handle this problem.
>>
>> Unlike leaky-view problem, we don't need to worry about unexpected
>> qualifier distribution on either side of join, because a scan on table
>> never contains
On Wed, May 23, 2012 at 3:45 PM, Kohei KaiGai wrote:
> I wanted to have discussion to handle this problem.
>
> Unlike leaky-view problem, we don't need to worry about unexpected
> qualifier distribution on either side of join, because a scan on table
> never contains any join. Thus, all we need to
2012/5/23 Alastair Turner :
> On Wed, May 23, 2012 at 5:09 PM, Tom Lane wrote:
>> Kohei KaiGai writes:
>>> Let me have a discussion to get preferable interface for row-level security.
>>> My planned feature will perform to append additional conditions to WHERE
>>> clause implicitly, to restrict t
2012/5/23 Tom Lane :
> Kohei KaiGai writes:
>> Let me have a discussion to get preferable interface for row-level security.
>> My planned feature will perform to append additional conditions to WHERE
>> clause implicitly, to restrict tuples being visible for the current user.
>> For example, when
On Wed, May 23, 2012 at 5:09 PM, Tom Lane wrote:
> Kohei KaiGai writes:
>> Let me have a discussion to get preferable interface for row-level security.
>> My planned feature will perform to append additional conditions to WHERE
>> clause implicitly, to restrict tuples being visible for the curren
Kohei KaiGai writes:
> Let me have a discussion to get preferable interface for row-level security.
> My planned feature will perform to append additional conditions to WHERE
> clause implicitly, to restrict tuples being visible for the current user.
> For example, when row-level policy "uname = g
Let me have a discussion to get preferable interface for row-level security.
My planned feature will perform to append additional conditions to WHERE
clause implicitly, to restrict tuples being visible for the current user.
For example, when row-level policy "uname = getpgusername()" is configured
64 matches
Mail list logo
