Re: [HACKERS] security label support, part.2

2010-08-27 Thread Robert Haas
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

Re: [HACKERS] security label support, part.2

2010-08-24 Thread KaiGai Kohei
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

Re: [HACKERS] security label support, part.2

2010-08-22 Thread Peter Eisentraut
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

Re: [HACKERS] security label support, part.2

2010-08-22 Thread Stephen Frost
* 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

Re: [HACKERS] security label support, part.2

2010-08-22 Thread Peter Eisentraut
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

Re: [HACKERS] security label support, part.2

2010-08-22 Thread Stephen Frost
* 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

Re: [HACKERS] security label support, part.2

2010-08-18 Thread Robert Haas
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

Re: [HACKERS] security label support, part.2

2010-08-18 Thread Stephen Frost
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

Re: [HACKERS] security label support, part.2

2010-08-18 Thread Stephen Frost
* 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

Re: [HACKERS] security label support, part.2

2010-08-18 Thread Robert Haas
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

Re: [HACKERS] security label support, part.2

2010-08-18 Thread KaiGai Kohei
(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

Re: [HACKERS] security label support, part.2

2010-08-18 Thread KaiGai Kohei
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

Re: [HACKERS] security label support, part.2

2010-08-17 Thread Kevin Grittner
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

Re: [HACKERS] security label support, part.2

2010-08-17 Thread Kevin Grittner
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

Re: [HACKERS] security label support, part.2

2010-08-17 Thread Stephen Frost
* 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

Re: [HACKERS] security label support, part.2

2010-08-17 Thread Robert Haas
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,

Re: [HACKERS] security label support, part.2

2010-08-17 Thread Stephen Frost
* 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

Re: [HACKERS] security label support, part.2

2010-08-17 Thread Tom Lane
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

Re: [HACKERS] security label support, part.2

2010-08-17 Thread KaiGai Kohei
(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

Re: [HACKERS] security label support, part.2

2010-08-17 Thread Stephen Frost
* 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

Re: [HACKERS] security label support, part.2

2010-08-17 Thread KaiGai Kohei
(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

Re: [HACKERS] security label support, part.2

2010-08-17 Thread Stephen Frost
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

Re: [HACKERS] security label support, part.2

2010-08-17 Thread Robert Haas
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

Re: [HACKERS] security label support, part.2

2010-08-17 Thread KaiGai Kohei
(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

Re: [HACKERS] security label support, part.2

2010-08-16 Thread Stephen Frost
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

Re: [HACKERS] security label support, part.2

2010-08-16 Thread Kevin Grittner
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

Re: [HACKERS] security label support, part.2

2010-08-16 Thread Stephen Frost
* 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

Re: [HACKERS] security label support, part.2

2010-08-16 Thread KaiGai Kohei
(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,

Re: [HACKERS] security label support, part.2

2010-08-16 Thread Stephen Frost
* 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

Re: [HACKERS] security label support, part.2

2010-08-16 Thread KaiGai Kohei
(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

Re: [HACKERS] security label support, part.2

2010-08-16 Thread Tom Lane
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

Re: [HACKERS] security label support, part.2

2010-08-16 Thread KaiGai Kohei
(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

Re: [HACKERS] security label support, part.2

2010-08-16 Thread Peter Eisentraut
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

Re: [HACKERS] security label support, part.2

2010-08-16 Thread KaiGai Kohei
(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

Re: [HACKERS] security label support, part.2

2010-08-15 Thread KaiGai Kohei
(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

Re: [HACKERS] security label support, part.2

2010-08-14 Thread KaiGai Kohei
(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

Re: [HACKERS] security label support, part.2

2010-08-14 Thread Stephen Frost
* 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.

Re: [HACKERS] security label support, part.2

2010-08-14 Thread KaiGai Kohei
(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

Re: [HACKERS] security label support, part.2

2010-08-14 Thread Robert Haas
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

Re: [HACKERS] security label support, part.2

2010-08-09 Thread Robert Haas
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

Re: [HACKERS] security label support, part.2

2010-08-09 Thread kaigai
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:

Re: [HACKERS] security label support, part.2

2010-08-09 Thread Robert Haas
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,

Re: [HACKERS] security label support, part.2

2010-07-26 Thread KaiGai Kohei
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

Re: [HACKERS] security label support, part.2

2010-07-23 Thread Robert Haas
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

Re: [HACKERS] security label support, part.2

2010-07-23 Thread Stephen Frost
* 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-

Re: [HACKERS] security label support, part.2

2010-07-23 Thread Robert Haas
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

Re: [HACKERS] security label support, part.2

2010-07-23 Thread KaiGai Kohei
(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

Re: [HACKERS] security label support, part.2

2010-07-23 Thread Robert Haas
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

Re: [HACKERS] security label support, part.2

2010-07-22 Thread Robert Haas
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 ...,

Re: [HACKERS] security label support, part.2

2010-07-22 Thread KaiGai Kohei
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:

Re: [HACKERS] security label support, part.2

2010-07-22 Thread Robert Haas
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

Re: [HACKERS] security label support, part.2

2010-07-22 Thread KaiGai Kohei
(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()

Re: [HACKERS] security label support, part.2

2010-07-22 Thread Robert Haas
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

Re: [HACKERS] security label support, part.2

2010-07-22 Thread KaiGai Kohei
(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

[HACKERS] security label support, part.2

2010-07-13 Thread KaiGai Kohei
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