Re: security label support, revised - Mailing list pgsql-hackers

(2010/09/27 11:49), Robert Haas wrote:
> On Sat, Sep 25, 2010 at 7:04 AM, KaiGai Kohei<kaigai@kaigai.gr.jp>  wrote:
>> * The "dummy_esp" module and regression test for SECURITY LABEL statement.
>>   This module allows only four labels: "unclassified", "classified",
>>   "secret" and "top secret". The later two labels can be set by only
>>   superusers. The new regression test uses this "dummy_esp" module to
>>   find out future regression in SECURITY LABEL statement.
>> * A minimum description about external security provider at the tail
>>   of Database Roles and Privileges  chapter.
>> * Add pg_seclabels system view
>> * Revising pg_dump/pg_dumpall
>>   - '--security-label' was replaced by '--no-security-label'
>>   - implemented according to the manner in comments.
>>     findSecLabels() and collectSecLabels() are added to reduce number of
>>     SQL queries, in addition to dumpSecLabel().
>
> Thanks, this looks like mostly good stuff.  Here's a new version of
> the patch with some bug fixes, additional regression tests, and other
> cleanup.  I think this is about ready to commit.

Thanks for your reviewing and cleaning-up.

> I didn't adopt your
> documentation and I renamed your contrib module from dummy_esp to
> dummy_seclabel, but the rest I took more or less as you had it.

Fair enough. I intended the name of "dummy_esp" to host any other
upcoming regression tests corresponding to security hooks, but
right now it just provides dummy labels.

> For
> now, I don't want to use the term "external security provider" because
> that's not really what this provides - it just provides labels.  I
> initially thought that an external security provider would really turn
> out to be a concept that was somewhat embedded in the system, but on
> further reflection I don't think that's the case.  I think what we're
> going to end up with is a collection of hooks that might happen to be
> useful for security-related things, but not necessarily just those.

Right, the "security provider" plugin which uses the collection of
security hooks will provides access control decision, but we don't
force anything in the way to make decisions.
Someone may provide label based security, but other one may provide
non-label based security.
All we can say is that guest of the hook on SECURITY LABEL provides
security label, but it is unclear whether it also provides any access
control, or not.
I also think the "label provider" is a fair enough naming.

> Anyway, I feel that it's a bit premature to document too much about
> what this might do someday; the documentation already in the patch is
> adequate to explain what it does now.
>
I agreed. It is quite internal stuff how security hooks should perform
on interactions with plugin modules, so it might be premature.

Thanks,
--
KaiGai Kohei <kaigai@kaigai.gr.jp>