2010/10/17 KaiGai Kohei kai...@ak.jp.nec.com:
(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
(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 to
(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're not
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
2010/10/11 KaiGai Kohei kai...@ak.jp.nec.com:
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
(2010/10/12 20:59), Robert Haas wrote:
2010/10/11 KaiGai Koheikai...@ak.jp.nec.com:
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
On Tue, Oct 12, 2010 at 9:20 AM, KaiGai Kohei kai...@kaigai.gr.jp 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
(2010/10/12 23:09), Robert Haas wrote:
On Tue, Oct 12, 2010 at 9:20 AM, KaiGai Koheikai...@kaigai.gr.jp 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
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.
On Mon, Oct 11, 2010 at 9:58 PM, KaiGai Kohei kai...@ak.jp.nec.com 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
(2010/10/12 11:35), Robert Haas wrote:
On Mon, Oct 11, 2010 at 9:58 PM, KaiGai Koheikai...@ak.jp.nec.com 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
On Wed, Oct 6, 2010 at 5:21 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Robert Haas's message of mié oct 06 17:02:22 -0400 2010:
2010/10/5 KaiGai Kohei kai...@ak.jp.nec.com:
However, we also have a few headache cases.
DefineType() creates a new type object and its
(2010/10/08 0:21), Robert Haas wrote:
On Wed, Oct 6, 2010 at 5:21 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Robert Haas's message of mié oct 06 17:02:22 -0400 2010:
2010/10/5 KaiGai Koheikai...@ak.jp.nec.com:
However, we also have a few headache cases.
DefineType()
2010/10/5 KaiGai Kohei kai...@ak.jp.nec.com:
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
Excerpts from Robert Haas's message of mié oct 06 17:02:22 -0400 2010:
2010/10/5 KaiGai Kohei kai...@ak.jp.nec.com:
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
(2010/10/07 6:02), Robert Haas wrote:
2010/10/5 KaiGai Koheikai...@ak.jp.nec.com:
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
(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 Koheikai...@ak.jp.nec.com:
However, we also have a few headache cases.
DefineType() creates a new type object and its array type, but it does not
call
(2010/10/01 11:23), Robert Haas wrote:
On Sep 30, 2010, at 9:01 PM, KaiGai Koheikai...@ak.jp.nec.com wrote:
(2010/10/01 3:09), Robert Haas wrote:
2010/9/29 KaiGai Koheikai...@ak.jp.nec.com:
In addition, I want to give these entrypoints its name which
represents an appropriate purpose of the
2010/9/29 KaiGai Kohei kai...@ak.jp.nec.com:
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
(2010/10/01 3:09), Robert Haas wrote:
2010/9/29 KaiGai Koheikai...@ak.jp.nec.com:
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
On Sep 30, 2010, at 9:01 PM, KaiGai Kohei kai...@ak.jp.nec.com wrote:
(2010/10/01 3:09), Robert Haas wrote:
2010/9/29 KaiGai Koheikai...@ak.jp.nec.com:
In addition, I want to give these entrypoints its name which
represents an appropriate purpose of the hook, rather than
a uniformed one.
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 Koheikai...@ak.jp.nec.com:
This patch allows external security providers to check privileges
to create a new relation and to inform
On Wed, Sep 29, 2010 at 6:38 AM, KaiGai Kohei kai...@kaigai.gr.jp 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
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 Koheikai...@ak.jp.nec.com:
This patch allows external security providers to check privileges
to create a new relation and to inform the security labels to be
(2010/09/29 22:00), Robert Haas wrote:
On Wed, Sep 29, 2010 at 6:38 AM, KaiGai Koheikai...@kaigai.gr.jp 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
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
On Wed, Sep 29, 2010 at 9:59 AM, KaiGai Kohei kai...@kaigai.gr.jp wrote:
(2010/09/29 22:00), Robert Haas wrote:
On Wed, Sep 29, 2010 at 6:38 AM, KaiGai Koheikai...@kaigai.gr.jp wrote:
I don't think it is an option to move the hook after the pollution
of system catalogs, although we can pull
(2010/09/30 0:36), Robert Haas wrote:
On Wed, Sep 29, 2010 at 9:59 AM, KaiGai Koheikai...@kaigai.gr.jp wrote:
(2010/09/29 22:00), Robert Haas wrote:
On Wed, Sep 29, 2010 at 6:38 AM, KaiGai Koheikai...@kaigai.gr.jpwrote:
I don't think it is an option to move the hook after the pollution
2010/9/29 KaiGai Kohei kai...@ak.jp.nec.com:
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
(2010/09/30 10:28), Robert Haas wrote:
2010/9/29 KaiGai Koheikai...@ak.jp.nec.com:
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
2010/9/1 KaiGai Kohei kai...@ak.jp.nec.com:
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.
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
32 matches
Mail list logo
