2010/8/25 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 t
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
>
* 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 chil
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 o
* 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 pare
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 lea
>>> 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
(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 t
On Wed, Aug 18, 2010 at 8:49 AM, Stephen Frost 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
> depending on the spec
* 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 o
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
2010/8/18 KaiGai Kohei :
>> 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 wants to handl
(2010/08/18 12:02), Robert Haas wrote:
> 2010/8/17 KaiGai Kohei:
>>> 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 con
2010/8/17 KaiGai Kohei :
>> 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 child table coul
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 inhe
(2010/08/18 9:04), Stephen Frost wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Robert Haas 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 di
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Robert Haas 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 SQL spec requir
(2010/08/18 3:07), Robert Haas wrote:
> On Tue, Aug 17, 2010 at 1:50 PM, Stephen Frost 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 f
Robert Haas writes:
> On Tue, Aug 17, 2010 at 1:50 PM, Stephen Frost 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 environmen
* Robert Haas (robertmh...@gmail.com) wrote:
> On Tue, Aug 17, 2010 at 1:50 PM, Stephen Frost 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
On Tue, Aug 17, 2010 at 1:50 PM, Stephen Frost 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, it's arguably incor
* Kevin Grittner (kevin.gritt...@wicourts.gov) wrote:
> >Stephen Frost 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.
>
>Stephen Frost 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 something at le
>Stephen Frost 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 we're working
(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
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 pgsql
(2010/08/17 11:58), Tom Lane wrote:
> Stephen Frost 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 acc
Stephen Frost 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 tables.
> I tend
(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 th
* 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 a
(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
* 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 woul
>Stephen Frost 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 Wisconsin Courts, a
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 wit
(2010/08/15 9:55), Robert Haas wrote:
> 2010/8/14 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
>>
2010/8/14 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 indi
(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.
>
> Th
* 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/10 8:39), Robert Haas wrote:
2010/8/9:
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 DeleteLocalSecL
2010/8/9 :
>> 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, SetSecurityLabel
>> a
Thanks for your reviewing.
On Mon, 9 Aug 2010 16:02:12 -0400
Robert Haas wrote:
> 2010/7/26 KaiGai Kohei :
> > 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 ob
2010/7/26 KaiGai Kohei :
> 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 that can go in. And i
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 ] ON IS
'';
E.g) SECURITY LABEL ON TABLE t1 IS 'system_u:object_r:sepgsql_tab
On Fri, Jul 23, 2010 at 8:59 AM, KaiGai Kohei wrote:
> (2010/07/23 20:44), Robert Haas wrote:
>>
>> 2010/7/23 KaiGai Kohei:
Hmm. How about if there's just one provider loaded, you can omit it,
but if you fail to specify it and there's>1 loaded, we just throw an
error saying yo
(2010/07/23 20:44), Robert Haas wrote:
2010/7/23 KaiGai Kohei:
Hmm. How about if there's just one provider loaded, you can omit it,
but if you fail to specify it and there's>1 loaded, we just throw an
error saying you didn't specify whose label it is.
Perhaps, we need to return the caller a s
On Fri, Jul 23, 2010 at 8:32 AM, Stephen Frost 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 about only havin
* 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- o
2010/7/23 KaiGai Kohei :
>> Hmm. How about if there's just one provider loaded, you can omit it,
>> but if you fail to specify it and there's>1 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 provider che
(2010/07/23 12:56), Robert Haas wrote:
> 2010/7/22 KaiGai Kohei:
>>> 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 n
2010/7/22 KaiGai Kohei :
>> 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 perhaps SECURI
(2010/07/23 10:05), Robert Haas wrote:
> 2010/7/22 KaiGai Kohei:
>> 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 al
2010/7/22 KaiGai Kohei :
> 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 checks on the u
Thanks for your reviewing.
(2010/07/23 0:54), Robert Haas wrote:
> 2010/7/14 KaiGai Kohei:
>> 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 in
2010/7/14 KaiGai Kohei :
> 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 ...,
following COMMENT ON
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 cont
55 matches
Mail list logo
