Re: security label support, part.2

On Fri, Jul 23, 2010 at 8:59 AM, KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp> wrote:
> (2010/07/23 20:44), Robert Haas wrote:
>>
>> 2010/7/23 KaiGai Kohei<kaigai(at)ak(dot)jp(dot)nec(dot)com>:
>>>>
>>>> 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
>>> checked
>>> the given label at least, or not.
>>
>> Return to the caller?  This is an SQL command.  You either get an
>> error, or you don't.
>>
> Ahh, I was talked about relationship between the core PG code and ESP
> module.
> It means the security hook returns a state which informs the core PG code
> whether one provider checked the given label, then the core PG code can
> decide whether it raise an actual error to users, or not.
>
> In other words, I'd like to suggest the security hook which returns a tag
> of ESP module, as follows:
>
>  const char *
>  check_object_relabel_hook(const ObjectAddress *object,
>                            const char *provider,
>                            const char *seclabel);

I don't think that's a very good design. What I had in mind was a
simple API for security providers to register themselves (including
their names), and then the core code will only call the relevant
security provider. I did try to explain this in point #3 of my
original review.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company