Sorry for my late reply.
2012/6/6 Florian Pflug f...@phlo.org:
On Jun5, 2012, at 22:33 , Kohei KaiGai wrote:
2012/6/5 Florian Pflug f...@phlo.org:
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
2012/6/5 Tom Lane t...@sss.pgh.pa.us:
Florian Pflug f...@phlo.org writes:
On Jun4, 2012, at 18:38 , Kohei KaiGai wrote:
2012/6/4 Florian Pflug f...@phlo.org:
Without something like RLSBYPASS, the DBA needs to have intimate
knowledge about the different RLS policies to e.g. guarantee that his
On Jun5, 2012, at 10:22 , Kohei KaiGai wrote:
2012/6/5 Tom Lane t...@sss.pgh.pa.us:
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
2012/6/5 Florian Pflug f...@phlo.org:
On Jun5, 2012, at 10:22 , Kohei KaiGai wrote:
2012/6/5 Tom Lane t...@sss.pgh.pa.us:
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
On Jun5, 2012, at 11:43 , Kohei KaiGai wrote:
2012/6/5 Florian Pflug f...@phlo.org:
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
2012/6/5 Florian Pflug f...@phlo.org:
On Jun5, 2012, at 11:43 , Kohei KaiGai wrote:
2012/6/5 Florian Pflug f...@phlo.org:
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
On Jun5, 2012, at 15:07 , Kohei KaiGai wrote:
2012/6/5 Florian Pflug f...@phlo.org:
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
2012/6/5 Florian Pflug f...@phlo.org:
On Jun5, 2012, at 15:07 , Kohei KaiGai wrote:
2012/6/5 Florian Pflug f...@phlo.org:
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
On Jun5, 2012, at 22:33 , Kohei KaiGai wrote:
2012/6/5 Florian Pflug f...@phlo.org:
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)
On Sat, Jun 2, 2012 at 12:58 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
2012/6/1 Robert Haas robertmh...@gmail.com:
On Thu, May 31, 2012 at 3:52 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
It may be an option to separate the case into two; a situation to execute
the given query immediately
2012/6/4 Robert Haas robertmh...@gmail.com:
On Sat, Jun 2, 2012 at 12:58 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
2012/6/1 Robert Haas robertmh...@gmail.com:
On Thu, May 31, 2012 at 3:52 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
It may be an option to separate the case into two; a
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 Florian Pflug f...@phlo.org:
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,
Kohei KaiGai kai...@kaigai.gr.jp 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
2012/6/4 Tom Lane t...@sss.pgh.pa.us:
Kohei KaiGai kai...@kaigai.gr.jp 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
On Jun4, 2012, at 18:38 , Kohei KaiGai wrote:
2012/6/4 Florian Pflug f...@phlo.org:
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
Florian Pflug f...@phlo.org writes:
On Jun4, 2012, at 18:38 , Kohei KaiGai wrote:
2012/6/4 Florian Pflug f...@phlo.org:
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
On Thu, May 31, 2012 at 3:52 PM, Kohei KaiGai kai...@kaigai.gr.jp 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
2012/6/1 Robert Haas robertmh...@gmail.com:
On Thu, May 31, 2012 at 3:52 PM, Kohei KaiGai kai...@kaigai.gr.jp 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
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,
2012/5/31 Yeb Havinga yebhavi...@gmail.com:
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,
On Wed, May 30, 2012 at 3:26 PM, Kohei KaiGai kai...@kaigai.gr.jp 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,
2012/5/31 Robert Haas robertmh...@gmail.com:
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,
2012/5/31 Kohei KaiGai kai...@kaigai.gr.jp:
2012/5/31 Robert Haas robertmh...@gmail.com:
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
2012/5/29 Robert Haas robertmh...@gmail.com:
On Fri, May 25, 2012 at 5:08 PM, Kohei KaiGai kai...@kaigai.gr.jp 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
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;
2012/5/27 Alastair Turner b...@ctrlf5.co.za:
Excerpts from Kohei KaiGai kai...@kaigai.gr.jp 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
2012/5/28 Florian Pflug f...@phlo.org:
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
On May29, 2012, at 13:59 , Kohei KaiGai wrote:
2012/5/28 Florian Pflug f...@phlo.org:
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
On May29, 2012, at 13:37 , Kohei KaiGai wrote:
2012/5/27 Alastair Turner b...@ctrlf5.co.za:
Excerpts from Kohei KaiGai kai...@kaigai.gr.jp 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
2012/5/29 Florian Pflug f...@phlo.org:
On May29, 2012, at 13:59 , Kohei KaiGai wrote:
2012/5/28 Florian Pflug f...@phlo.org:
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
On May29, 2012, at 16:13 , Kohei KaiGai wrote:
2012/5/29 Florian Pflug f...@phlo.org:
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
2012/5/29 Florian Pflug f...@phlo.org:
On May29, 2012, at 13:37 , Kohei KaiGai wrote:
2012/5/27 Alastair Turner b...@ctrlf5.co.za:
Excerpts from Kohei KaiGai kai...@kaigai.gr.jp wrote on Fri, May 25,
2012 at 11:08 PM:
If we assume RLS is applied when user has
no privileges on tables, the
On Tue, May 29, 2012 at 9:12 AM, Florian Pflug f...@phlo.org wrote:
On May29, 2012, at 13:37 , Kohei KaiGai wrote:
2012/5/27 Alastair Turner b...@ctrlf5.co.za:
Excerpts from Kohei KaiGai kai...@kaigai.gr.jp wrote on Fri, May 25,
2012 at 11:08 PM:
If we assume RLS is applied when user has
no
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 (probably
2012/5/29 Robert Haas robertmh...@gmail.com:
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
On Fri, May 25, 2012 at 5:08 PM, Kohei KaiGai kai...@kaigai.gr.jp 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
On Tue, May 29, 2012 at 10:57 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
2012/5/29 Robert Haas robertmh...@gmail.com:
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
On May29, 2012, at 16:57 , Kohei KaiGai wrote:
2012/5/29 Robert Haas robertmh...@gmail.com:
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
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 still
Excerpts from Kohei KaiGai kai...@kaigai.gr.jp 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
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 to
2012/5/24 Robert Haas robertmh...@gmail.com:
On Thu, May 24, 2012 at 6:11 AM, Kohei KaiGai kai...@kaigai.gr.jp 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
2012/5/24 Robert Haas robertmh...@gmail.com:
On Thu, May 24, 2012 at 12:00 PM, Kohei KaiGai kai...@kaigai.gr.jp 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
2012/5/25 Florian Pflug f...@phlo.org:
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
2012/5/23 Robert Haas robertmh...@gmail.com:
On Wed, May 23, 2012 at 3:45 PM, Kohei KaiGai kai...@kaigai.gr.jp 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
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
2012/5/24 Florian Pflug f...@phlo.org:
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
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 are
2012/5/24 Florian Pflug f...@phlo.org:
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
On May24, 2012, at 16:19 , Kohei KaiGai wrote:
So, the proposed interface might be revised as follows:
ALTER TABLE tblname ADD SECURITY POLICY
func_name(args, ...) [FOR SELECT |
INSERT |
2012/5/24 Florian Pflug f...@phlo.org:
On May24, 2012, at 16:19 , Kohei KaiGai wrote:
So, the proposed interface might be revised as follows:
ALTER TABLE tblname ADD SECURITY POLICY
func_name(args, ...) [FOR SELECT |
INSERT |
I'd like to summarize the current design being discussed.
syntax:
ALTER TABLE tblname WITH ROW LEVEL SECURITY
( condition clause ) [FOR (SELECT | UPDATE | DELETE)];
ALTER TABLE tblname WITHOUT ROW LEVEL SECURITY;
I tried to patch the parser/gram.y, but here was syntax conflicts
on ADD
On Thu, May 24, 2012 at 6:11 AM, Kohei KaiGai kai...@kaigai.gr.jp 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.
On Thu, May 24, 2012 at 6:20 AM, Florian Pflug f...@phlo.org 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
On Thu, May 24, 2012 at 12:00 PM, Kohei KaiGai kai...@kaigai.gr.jp 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
On May24, 2012, at 18:42 , Kohei KaiGai wrote:
I'd like to summarize the current design being discussed.
syntax:
ALTER TABLE tblname WITH ROW LEVEL SECURITY
( condition clause ) [FOR (SELECT | UPDATE | DELETE)];
ALTER TABLE tblname WITHOUT ROW LEVEL SECURITY;
I tried to patch the
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 visible
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
Kohei KaiGai kai...@kaigai.gr.jp 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
On Wed, May 23, 2012 at 5:09 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Kohei KaiGai kai...@kaigai.gr.jp 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
2012/5/23 Tom Lane t...@sss.pgh.pa.us:
Kohei KaiGai kai...@kaigai.gr.jp 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
2012/5/23 Alastair Turner b...@ctrlf5.co.za:
On Wed, May 23, 2012 at 5:09 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Kohei KaiGai kai...@kaigai.gr.jp writes:
Let me have a discussion to get preferable interface for row-level security.
My planned feature will perform to append additional conditions
On Wed, May 23, 2012 at 3:45 PM, Kohei KaiGai kai...@kaigai.gr.jp 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,
64 matches
Mail list logo
