2010/8/25 KaiGai Kohei kai...@ak.jp.nec.com:
7. I think we need to write and include in the fine documentation some
big picture documentation about enhanced security providers. Of
course, we have to decide what we want to say. But the SECURITY LABEL
documentation is just kind of hanging out
7. I think we need to write and include in the fine documentation some
big picture documentation about enhanced security providers. Of
course, we have to decide what we want to say. But the SECURITY LABEL
documentation is just kind of hanging out there in space right now; it
needs to connect
On tis, 2010-08-17 at 20:04 -0400, Stephen Frost wrote:
What I'm thinking of is something like a warning if the permissions on
the child don't match those of the parent when the relationship is
created, or maybe forcibly setting the permissions on the child (with
a
NOTICE), so it's at least
* Peter Eisentraut (pete...@gmx.net) wrote:
I think there are perfectly good reasons to have different permissions
on parent and child tables. I don't see any reason to monkey around
with that.
Even though the permissions on the child table aren't invovled at all if
queried through the
On sön, 2010-08-22 at 15:08 -0400, Stephen Frost wrote:
* Peter Eisentraut (pete...@gmx.net) wrote:
I think there are perfectly good reasons to have different permissions
on parent and child tables. I don't see any reason to monkey around
with that.
Even though the permissions on the
* Peter Eisentraut (pete...@gmx.net) wrote:
On sön, 2010-08-22 at 15:08 -0400, Stephen Frost wrote:
Even though the permissions on the child table aren't invovled at all if
queried through the parent..? The parent implicitly adds to the set of
privileges which are granted on the child, but
2010/8/18 KaiGai Kohei kai...@ak.jp.nec.com:
It's also worth pointing out that the hook in ExecCheckRTPerms() does
not presuppose label-based security. It could be used to implement
some other policy altogether, which only strengthens the argument that
we can't know how the user of the hook
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
If C1, C2, and C3 inherit from P, it's perfectly reasonable to grant
permissions to X on C1 and C2, Y on C3, and Z on C1, C2, C3, and P. I
don't think we should disallow that. Sure, it's possible to do things
that are less sane, but if we
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
If rte-requiredPerms would not be cleared, the user of the hook will
be able to check access rights on the child tables, as they like.
This would only be the case for those children which are being touched
in the current query, which would depend on
On Wed, Aug 18, 2010 at 8:49 AM, Stephen Frost sfr...@snowman.net wrote:
In the end, I'm thinking that if the external security module wants to
enforce a check against all the children of a parent, they could quite
possibly handle that already and do it in such a way that it won't break
(2010/08/18 21:52), Stephen Frost wrote:
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
If rte-requiredPerms would not be cleared, the user of the hook will
be able to check access rights on the child tables, as they like.
This would only be the case for those children which are being touched
How about an idea to add a new flag in RangeTblEntry which shows where
the RangeTblEntry came from, instead of clearing requiredPerms?
If the flag is true, I think ExecCheckRTEPerms() can simply skip checks
on the child tables.
How about the external module just checks if the current object
Stephen Frost sfr...@snowman.net wrote:
Let's not build the complication of dealing with inheiritance/
child relations into the external security system when we're in
the middle of trying to get rid of that distinction in core PG
though.
I didn't realize we were trying to do that. I know
Stephen Frost sfr...@snowman.net wrote:
No.. and I'm not sure we ever would. What we *have* done is
removed all permissions checking on child tables when a parent is
being queried..
OK, that clarifies things. Thanks.
So, essentially that means that you need to set all ancestor levels
to
* Kevin Grittner (kevin.gritt...@wicourts.gov) wrote:
Stephen Frost sfr...@snowman.net wrote:
Let's not build the complication of dealing with inheiritance/
child relations into the external security system when we're in
the middle of trying to get rid of that distinction in core PG
On Tue, Aug 17, 2010 at 1:50 PM, Stephen Frost sfr...@snowman.net wrote:
No.. and I'm not sure we ever would. What we *have* done is removed
all permissions checking on child tables when a parent is being
queried..
Yeah. I'm not totally sure that is sensible for a MAC environment.
Heck,
* Robert Haas (robertmh...@gmail.com) wrote:
On Tue, Aug 17, 2010 at 1:50 PM, Stephen Frost sfr...@snowman.net wrote:
No.. and I'm not sure we ever would. What we *have* done is removed
all permissions checking on child tables when a parent is being
queried..
Yeah. I'm not totally
Robert Haas robertmh...@gmail.com writes:
On Tue, Aug 17, 2010 at 1:50 PM, Stephen Frost sfr...@snowman.net wrote:
No.. and I'm not sure we ever would. What we *have* done is removed
all permissions checking on child tables when a parent is being
queried..
Yeah. I'm not totally sure that
(2010/08/18 3:07), Robert Haas wrote:
On Tue, Aug 17, 2010 at 1:50 PM, Stephen Frostsfr...@snowman.net wrote:
No.. and I'm not sure we ever would. What we *have* done is removed
all permissions checking on child tables when a parent is being
queried..
Yeah. I'm not totally sure that is
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Robert Haas robertmh...@gmail.com writes:
Yeah. I'm not totally sure that is sensible for a MAC environment.
Heck, it's arguably incorrect (though perhaps quite convenient) in a
DAC environment.
IIRC, the reason we did it was that we decided the
(2010/08/18 9:04), Stephen Frost wrote:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Robert Haasrobertmh...@gmail.com writes:
Yeah. I'm not totally sure that is sensible for a MAC environment.
Heck, it's arguably incorrect (though perhaps quite convenient) in a
DAC environment.
IIRC, the reason
KaiGai,
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
I believed that table inheritance is a unique feature in PostgreSQL.
It's actually not..
Does the SQL spec really mention about whether a child table is an
independent table object, or not?
The SQL spec does discuss 'subtables' and
2010/8/17 KaiGai Kohei kai...@ak.jp.nec.com:
I dunno. None of the above makes me feel very comfortable from a
security perspective because I'm concerned any of the above could too
easily be overlooked by someone upgrading. It also doesn't really
address the concern that, at some point, a
(2010/08/18 12:02), Robert Haas wrote:
2010/8/17 KaiGai Koheikai...@ak.jp.nec.com:
I dunno. None of the above makes me feel very comfortable from a
security perspective because I'm concerned any of the above could too
easily be overlooked by someone upgrading. It also doesn't really
address
KaiGai,
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
The purpose of this restriction is to ensure an access control decision
using parent's label being also consistent on child tables.
Robert and I understand the concern that you have. The answer, at least
for now, is that we don't agree with
Stephen Frost sfr...@snowman.net wrote:
PG doesn't consider child tables to be independent objects when
they're being accessed through the parent. As such, they don't
have their own permissions checking.
I've been thinking about this from the perspective of possible
eventual use by the
* Kevin Grittner (kevin.gritt...@wicourts.gov) wrote:
Many of the features KaiGai has discussed would fit nicely with
court requirements -- and might even be prerequisites for
considering moving security to the database level. Mandating
identical security for all tables in a hierarchy would
(2010/08/16 22:14), Stephen Frost wrote:
KaiGai,
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
The purpose of this restriction is to ensure an access control decision
using parent's label being also consistent on child tables.
Robert and I understand the concern that you have. The answer,
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
Ahh, yes, the question is what is an object, not a MAC vs DAC.
Indeed, PG does not try to handle child table as an independent object
from a parent table. However, if so, it seems to me strange that we can
assign individual ownership and access
(2010/08/17 9:51), Stephen Frost wrote:
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
Ahh, yes, the question is what is an object, not a MAC vs DAC.
Indeed, PG does not try to handle child table as an independent object
from a parent table. However, if so, it seems to me strange that we can
Stephen Frost sfr...@snowman.net writes:
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
Indeed, PG does not try to handle child table as an independent object
from a parent table. However, if so, it seems to me strange that we can
assign individual ownership and access privileges on child
(2010/08/17 11:58), Tom Lane wrote:
Stephen Frostsfr...@snowman.net writes:
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
Indeed, PG does not try to handle child table as an independent object
from a parent table. However, if so, it seems to me strange that we can
assign individual ownership
On tis, 2010-08-17 at 13:00 +0900, KaiGai Kohei wrote:
However, isn't it strange if we stand on the perspective that child
table is a part of parent object? It means an object have multiple
properties depending on the context.
Such is the nature of inheritance, isn't it?
--
Sent via
(2010/08/17 13:28), Peter Eisentraut wrote:
On tis, 2010-08-17 at 13:00 +0900, KaiGai Kohei wrote:
However, isn't it strange if we stand on the perspective that child
table is a part of parent object? It means an object have multiple
properties depending on the context.
Such is the nature
(2010/08/15 9:55), Robert Haas wrote:
2010/8/14 KaiGai Koheikai...@kaigai.gr.jp:
(2010/08/15 9:16), Stephen Frost wrote:
* KaiGai Kohei (kai...@kaigai.gr.jp) wrote:
Yep, rte-requiredPerms of inherited relations are cleared on the
expand_inherited_rtentry() since the v9.0, so we cannot know
(2010/08/10 8:39), Robert Haas wrote:
2010/8/9kai...@kaigai.gr.jp:
2. Some of this code refers to local security labels. I'm not sure
what's local about them - aren't they just security labels? On a
related note, I don't like the trivial wrappers you have here, with
DeleteSecurityLabel around
* KaiGai Kohei (kai...@kaigai.gr.jp) wrote:
Yep, rte-requiredPerms of inherited relations are cleared on the
expand_inherited_rtentry() since the v9.0, so we cannot know what
kind of accesses are required on the individual child relations.
This is really a PG issue and decision, in my view.
(2010/08/15 9:16), Stephen Frost wrote:
* KaiGai Kohei (kai...@kaigai.gr.jp) wrote:
Yep, rte-requiredPerms of inherited relations are cleared on the
expand_inherited_rtentry() since the v9.0, so we cannot know what
kind of accesses are required on the individual child relations.
This is
2010/8/14 KaiGai Kohei kai...@kaigai.gr.jp:
(2010/08/15 9:16), Stephen Frost wrote:
* KaiGai Kohei (kai...@kaigai.gr.jp) wrote:
Yep, rte-requiredPerms of inherited relations are cleared on the
expand_inherited_rtentry() since the v9.0, so we cannot know what
kind of accesses are required on
2010/7/26 KaiGai Kohei kai...@ak.jp.nec.com:
The attached patches are revised ones, as follows.
I think this is pretty good, and I'm generally in favor of committing
it. Some concerns:
1. Since nobody has violently objected to the comment.c refactoring
patch I recently proposed, I'm hopeful
Thanks for your reviewing.
On Mon, 9 Aug 2010 16:02:12 -0400
Robert Haas robertmh...@gmail.com wrote:
2010/7/26 KaiGai Kohei kai...@ak.jp.nec.com:
The attached patches are revised ones, as follows.
I think this is pretty good, and I'm generally in favor of committing
it. Some concerns:
2010/8/9 kai...@kaigai.gr.jp:
2. Some of this code refers to local security labels. I'm not sure
what's local about them - aren't they just security labels? On a
related note, I don't like the trivial wrappers you have here, with
DeleteSecurityLabel around DeleteLocalSecLabel,
The attached patches are revised ones, as follows.
* A new SECURITY LABEL statement replaced the previous ALTER TABLE statement
with SECURITY LABEL TO option. It has the following syntax.
SECURITY LABEL [ FOR provider ] ON object class object name IS
'label';
E.g) SECURITY LABEL ON TABLE
2010/7/23 KaiGai Kohei kai...@ak.jp.nec.com:
Hmm. How about if there's just one provider loaded, you can omit it,
but if you fail to specify it and there's1 loaded, we just throw an
error saying you didn't specify whose label it is.
Perhaps, we need to return the caller a state whether one
* Robert Haas (robertmh...@gmail.com) wrote:
I don't understand why we wouldn't be able to support multiple
providers for row-level security. Why do you think that's a problem?
My guess would be that he's concerned about only having space in the
tuple header for 1 label. I see two answers-
On Fri, Jul 23, 2010 at 8:32 AM, Stephen Frost sfr...@snowman.net wrote:
* Robert Haas (robertmh...@gmail.com) wrote:
I don't understand why we wouldn't be able to support multiple
providers for row-level security. Why do you think that's a problem?
My guess would be that he's concerned
(2010/07/23 20:44), Robert Haas wrote:
2010/7/23 KaiGai Koheikai...@ak.jp.nec.com:
Hmm. How about if there's just one provider loaded, you can omit it,
but if you fail to specify it and there's1 loaded, we just throw an
error saying you didn't specify whose label it is.
Perhaps, we need to
On Fri, Jul 23, 2010 at 8:59 AM, KaiGai Kohei kai...@kaigai.gr.jp wrote:
(2010/07/23 20:44), Robert Haas wrote:
2010/7/23 KaiGai Koheikai...@ak.jp.nec.com:
Hmm. How about if there's just one provider loaded, you can omit it,
but if you fail to specify it and there's1 loaded, we just throw
2010/7/14 KaiGai Kohei kai...@ak.jp.nec.com:
The attached patch is a part of efforts to support security label
on database objects.
This is similar to what I had in mind as a design for this feature,
but I have some gripes:
1. I am inclined to suggest the syntax SECURITY LABEL ON ... IS ...,
Thanks for your reviewing.
(2010/07/23 0:54), Robert Haas wrote:
2010/7/14 KaiGai Koheikai...@ak.jp.nec.com:
The attached patch is a part of efforts to support security label
on database objects.
This is similar to what I had in mind as a design for this feature,
but I have some gripes:
2010/7/22 KaiGai Kohei kai...@ak.jp.nec.com:
Thanks for your reviewing.
1. I am inclined to suggest the syntax SECURITY LABEL ON ... IS ...,
following COMMENT ON (it's also somewhat similar to the GRANT syntax).
While the hook in ExecCheckRTPerms() will only allow meaningful
permissions
(2010/07/23 10:05), Robert Haas wrote:
2010/7/22 KaiGai Koheikai...@ak.jp.nec.com:
Thanks for your reviewing.
1. I am inclined to suggest the syntax SECURITY LABEL ON ... IS ...,
following COMMENT ON (it's also somewhat similar to the GRANT syntax).
While the hook in ExecCheckRTPerms()
2010/7/22 KaiGai Kohei kai...@ak.jp.nec.com:
Well, I like SECURITY LABEL better because it's more clear about what
kind of label we're talking about, but if there's consensus on some
other option it's OK with me. Actually, we need to work the security
provider name in there too, I think, so
(2010/07/23 12:56), Robert Haas wrote:
2010/7/22 KaiGai Koheikai...@ak.jp.nec.com:
Well, I like SECURITY LABEL better because it's more clear about what
kind of label we're talking about, but if there's consensus on some
other option it's OK with me. Actually, we need to work the security
The attached patch is a part of efforts to support security label
on database objects.
It adds statement support to manage security label of relations.
Right now, object labeling except for relations/columns are not
supported, because the DML permission hook is the only chance to
apply access
55 matches
Mail list logo
