From: | KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Alvaro Herrera <alvherre(at)commandprompt(dot)com>, KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>, PgSQL-Hackers <pgsql-hackers(at)postgresql(dot)org>, Joshua Brindle <method(at)manicmethod(dot)com>, "David P(dot) Quigley" <dpquigl(at)tycho(dot)nsa(dot)gov> |
Subject: | Re: security hook on table creation |
Date: | 2010-10-08 00:39:12 |
Message-ID: | 4CAE6830.50901@ak.jp.nec.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
(2010/10/08 0:21), Robert Haas wrote:
> On Wed, Oct 6, 2010 at 5:21 PM, Alvaro Herrera
> <alvherre(at)commandprompt(dot)com> wrote:
>> Excerpts from Robert Haas's message of mié oct 06 17:02:22 -0400 2010:
>>> 2010/10/5 KaiGai Kohei<kaigai(at)ak(dot)jp(dot)nec(dot)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 function, so the new type
>>>> entries are not visible from the plugin modules, even if we put a security
>>>> hook at tail of the DefineType().
>>>> DefineFunction() also has same matter. It create a new procedure object,
>>>> but it also does not call CommandCounterIncrement() by the end of this
>>>> function, except for the case when ProcedureCreate() invokes language
>>>> validator function.
>>>
>>> So I guess the first question here is why it's important to be able to
>>> see the new entry. I am thinking that you want it so that, for
>>> example, you can fetch the namespace OID to perform an SE-Linux type
>>> transition. Is that right?
>>
>> I'm not sure that there's any point trying to optimize these to the
>> point of avoiding CommandCounterIncrement. Surely DefineType et al are
>> not performance-sensitive operations.
>
> OK, fair enough. Let's just do it unconditionally then.
>
I guess we will need to have such kind of discussion whenever we touch
the code around security hooks in the future, if hooks would not be put
next to the existing DAC checks.
Although we need to define several hooks on object creation in addition
to the main hook, separating it into two parts helps us to understand
and maintenance.
| In the case when we have two hooks, obviously, the prep-creation
| hook will be after the DAC checks, and the post-creation hook will
| be after the insert/update of system catalogs.
I still don't think such a simple principle overs our capability, and
also don't think it is more complex than matters around the idea of
only post-creation hooks, such as CommandCounterIncrement().
Thanks,
--
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2010-10-08 00:49:22 | GIN vs. Partial Indexes |
Previous Message | Tom Lane | 2010-10-08 00:33:03 | Re: I: About "Our CLUSTER implementation is pessimal" patch |