(2010/10/18 23:14), Robert Haas wrote:
>> If MVCC visibility always would match with existing permission checks,
>> we don't need to pay special attention for these things, do we?
>
> It seems to me that you're worrying about the wrong set of problems.
> The original purpose of what I proposed was
2010/10/17 KaiGai Kohei :
> (2010/10/15 22:04), Stephen Frost wrote:
>> KaiGai,
>>
>> * KaiGai Kohei (kai...@kaigai.gr.jp) wrote:
>>> However, it requires the plugin modules need to know everything;
>>> such as what is visible/invisible. It seems to me too closely-
>>> coupled interface.
>>
>> I ag
(2010/10/15 22:04), Stephen Frost wrote:
> KaiGai,
>
> * KaiGai Kohei (kai...@kaigai.gr.jp) wrote:
>> However, it requires the plugin modules need to know everything;
>> such as what is visible/invisible. It seems to me too closely-
>> coupled interface.
>
> I agree with Robert on this one. We'r
KaiGai,
* KaiGai Kohei (kai...@kaigai.gr.jp) wrote:
> However, it requires the plugin modules need to know everything;
> such as what is visible/invisible. It seems to me too closely-
> coupled interface.
I agree with Robert on this one. We're not trying to design a wholly
independent security m
(2010/10/12 23:09), Robert Haas wrote:
> On Tue, Oct 12, 2010 at 9:20 AM, KaiGai Kohei wrote:
>> As I introduced before, the idea of two hooks makes obvious where
>> we should put the security hooks; it is next to the existing DAC
>> checking. It is the best guideline, even if we will touch the co
On Tue, Oct 12, 2010 at 9:20 AM, KaiGai Kohei wrote:
> As I introduced before, the idea of two hooks makes obvious where
> we should put the security hooks; it is next to the existing DAC
> checking. It is the best guideline, even if we will touch the code
> around object creation in the future ve
(2010/10/12 20:59), Robert Haas wrote:
2010/10/11 KaiGai Kohei:
It enables us to put security hooks independent from MVCC visibility of
the new database object. If we pay attention for visibility of new database
object, it seems to me amount of things to understand and maintain will be
increased
2010/10/11 KaiGai Kohei :
> It enables us to put security hooks independent from MVCC visibility of
> the new database object. If we pay attention for visibility of new database
> object, it seems to me amount of things to understand and maintain will be
> increased, although MVCC visibility is fun
(2010/10/12 11:35), Robert Haas wrote:
> On Mon, Oct 11, 2010 at 9:58 PM, KaiGai Kohei wrote:
>> It seems to me the conclusion of this discussion is unclear.
>>
>> We commonly try to find out an approach that minimize code complexity
>> to understand and maintain, so the point of issue is clear, b
On Mon, Oct 11, 2010 at 9:58 PM, KaiGai Kohei wrote:
> It seems to me the conclusion of this discussion is unclear.
>
> We commonly try to find out an approach that minimize code complexity
> to understand and maintain, so the point of issue is clear, but we
> still don't reach same conclusion, be
It seems to me the conclusion of this discussion is unclear.
We commonly try to find out an approach that minimize code complexity
to understand and maintain, so the point of issue is clear, but we
still don't reach same conclusion, because both of two ideas have merits
and demerits each other.
(2010/10/08 0:21), Robert Haas wrote:
On Wed, Oct 6, 2010 at 5:21 PM, Alvaro Herrera
wrote:
Excerpts from Robert Haas's message of mié oct 06 17:02:22 -0400 2010:
2010/10/5 KaiGai Kohei:
However, we also have a few headache cases.
DefineType() creates a new type object and its array type,
On Wed, Oct 6, 2010 at 5:21 PM, Alvaro Herrera
wrote:
> Excerpts from Robert Haas's message of mié oct 06 17:02:22 -0400 2010:
>> 2010/10/5 KaiGai Kohei :
>
>> > However, we also have a few headache cases.
>> > DefineType() creates a new type object and its array type, but it does not
>> > call Co
(2010/10/07 6:21), Alvaro Herrera wrote:
Excerpts from Robert Haas's message of mié oct 06 17:02:22 -0400 2010:
2010/10/5 KaiGai Kohei:
However, we also have a few headache cases.
DefineType() creates a new type object and its array type, but it does not
call CommandCounterIncrement() by the
(2010/10/07 6:02), Robert Haas wrote:
> 2010/10/5 KaiGai Kohei:
>> I began to revise the security hooks, but I could find a few cases that does
>> not work with the approach of post-creation security hooks.
>> If we try to fix up the core PG routine to become suitable for the
>> post-creation
>> s
Excerpts from Robert Haas's message of mié oct 06 17:02:22 -0400 2010:
> 2010/10/5 KaiGai Kohei :
> > However, we also have a few headache cases.
> > DefineType() creates a new type object and its array type, but it does not
> > call CommandCounterIncrement() by the end of this function, so the ne
2010/10/5 KaiGai Kohei :
> I began to revise the security hooks, but I could find a few cases that does
> not work with the approach of post-creation security hooks.
> If we try to fix up the core PG routine to become suitable for the
> post-creation
> security hooks, it shall need to put more Com
(2010/10/01 11:23), Robert Haas wrote:
> On Sep 30, 2010, at 9:01 PM, KaiGai Kohei wrote:
>> (2010/10/01 3:09), Robert Haas wrote:
>>> 2010/9/29 KaiGai Kohei:
In addition, I want to give these entrypoints its name which
represents an appropriate purpose of the hook, rather than
a un
On Sep 30, 2010, at 9:01 PM, KaiGai Kohei wrote:
> (2010/10/01 3:09), Robert Haas wrote:
>> 2010/9/29 KaiGai Kohei:
>>> In addition, I want to give these entrypoints its name which
>>> represents an appropriate purpose of the hook, rather than
>>> a uniformed one.
>>
>> It sounds like you're prop
(2010/10/01 3:09), Robert Haas wrote:
> 2010/9/29 KaiGai Kohei:
>> In addition, I want to give these entrypoints its name which
>> represents an appropriate purpose of the hook, rather than
>> a uniformed one.
>
> It sounds like you're proposing to create a vast number of hooks
> rather than just
2010/9/29 KaiGai Kohei :
> In addition, I want to give these entrypoints its name which
> represents an appropriate purpose of the hook, rather than
> a uniformed one.
It sounds like you're proposing to create a vast number of hooks
rather than just one. If we have ~20 object types in the system,
(2010/09/30 10:28), Robert Haas wrote:
> 2010/9/29 KaiGai Kohei:
>>> But with that exception,
>>> they seemed to think that coarse-grained permissions would be fine for
>>> a basic implementation: perhaps even just install something in
>>> ProcessUtility_hook and bounce DDL across the board, so lon
2010/9/29 KaiGai Kohei :
>> But with that exception,
>> they seemed to think that coarse-grained permissions would be fine for
>> a basic implementation: perhaps even just install something in
>> ProcessUtility_hook and bounce DDL across the board, so long as it's
>> controlled by reference to the
(2010/09/30 0:36), Robert Haas wrote:
> On Wed, Sep 29, 2010 at 9:59 AM, KaiGai Kohei wrote:
>> (2010/09/29 22:00), Robert Haas wrote:
>>>
>>> On Wed, Sep 29, 2010 at 6:38 AM, KaiGai Koheiwrote:
I don't think it is an option to move the hook after the pollution
of system catalog
On Wed, Sep 29, 2010 at 9:59 AM, KaiGai Kohei wrote:
> (2010/09/29 22:00), Robert Haas wrote:
>>
>> On Wed, Sep 29, 2010 at 6:38 AM, KaiGai Kohei wrote:
>>>
>>> I don't think it is an option to move the hook after the pollution
>>> of system catalogs, although we can pull out any information abou
KaiGai,
* KaiGai Kohei (kai...@kaigai.gr.jp) wrote:
> All the existing security checks applies before modifying system catalogs.
>
> At least, I cannot find out any constructive reason why we try to apply
> permission checks on object creation time with different manner towards
> the existing priv
(2010/09/29 22:00), Robert Haas wrote:
On Wed, Sep 29, 2010 at 6:38 AM, KaiGai Kohei wrote:
I don't think it is an option to move the hook after the pollution
of system catalogs, although we can pull out any information about
the new relation from syscache.
Why not?
All the existing securit
Excerpts from KaiGai Kohei's message of mié sep 29 06:38:09 -0400 2010:
> (2010/09/28 12:57), Robert Haas wrote:
> > 2010/9/1 KaiGai Kohei:
> >> This patch allows external security providers to check privileges
> >> to create a new relation and to inform the security labels to be
> >> assigned on
On Wed, Sep 29, 2010 at 6:38 AM, KaiGai Kohei wrote:
> I don't think it is an option to move the hook after the pollution
> of system catalogs, although we can pull out any information about
> the new relation from syscache.
Why not?
> Sorry, it seems to me the idea simplifies the issue too much
Thanks for your reviewing, and sorry for delayed responding due to
the LinuxCon Japan for a couple of days.
(2010/09/28 12:57), Robert Haas wrote:
2010/9/1 KaiGai Kohei:
This patch allows external security providers to check privileges
to create a new relation and to inform the security labels
2010/9/1 KaiGai Kohei :
> This patch allows external security providers to check privileges
> to create a new relation and to inform the security labels to be
> assigned on the new one.
Review:
I took a brief look at this patch tonight and I think it's on the
wrong track. There's no reason for t
This patch allows external security providers to check privileges
to create a new relation and to inform the security labels to be
assigned on the new one.
This hook is put on DefineRelation() and OpenIntoRel(), but isn't
put on Boot_CreateStmt, create_toast_table() and make_new_heap(),
although t
32 matches
Mail list logo
