Re: security label support, revised

(2010/09/24 11:53), Robert Haas wrote:
> 2010/9/23 KaiGai Kohei<kaigai(at)ak(dot)jp(dot)nec(dot)com>:
>>> Most of the contents of the new documentation section on external
>>> security providers seemed irrelevant to me, which I guess I can only
>>> blame myself for since I was the one who asked for that section to be
>>> created, and I didn't specify what it should contain all that well. I
>>> took a try at rewriting it to be more on-topic, but it didn't amount
>>> to much so I ended up just ripping that part out completely.
>>>
>> One headache thing when I tried to describe the new documentation section
>> was what we should describe here, because whole of the chapters in Server
>> Administration are on the standpoint of users, not developers.
>>
>> Under the previous discussion, I suggested to move the most of descriptions
>> about external security providers into chapters in Internals, except for
>> a mention about a fact we have external security provider at the tail of
>> Database Roles and Privileges. How about the idea?
>> Perhaps, the chapters in Internals are appropriate place to introduce
>> specification of security hooks.
>
> Perhaps. I know that in the past we have not documented hook
> functions, and I'm thinking that there may be people (in particular,
> possibly Tom) who have strong feelings about keeping it that way.
> Even if that's not the case, once we do start documenting the hooks,
> we will presumably need to document all of them, and that may be more
> of a project than I really want to get into right now, especially if I
> will have to do much of the work myself. I'd be perfectly ecstatic if
> a committable patch spontaneously materialized, but...
>
If so, maybe, we should keep the scale of documentation to a minimum,
then, rest of the detailed specifications of hooks are kept as source
code comments.
Because authors of ESP obviously reference source code, the comments
will provide them enough information.

>>> Also, the pg_dump support for security labels should
>>> really reuse the existing design for comments, rather than inventing a
>>> new and less efficient method, unless there is some really compelling
>>> reason why the method used for comments won't work. Please send a
>>> reworked patch for just this directory (src/bin/pg_dump).
>>>
>> I intended to follow on the existing design for comments.
>> Could you suggest me how should it be fixed up the design?
>
> dumpComment calls findComments calls collectComments, which dumps all
> the comments in one query (not one query per object).
>
>> Because of the --no-security-label option, we need to dump security
>> labels in a separated section from comments. So, we cannot pack them
>> into "COMMENT" sections.
>
> I'm not proposing that - I just want to avoid sending so many database
> queries, if that's possible.
>
Ahh, Thanks. It makes me clear.
I'll revise dumpSecLabel to call findSecLabels and collectSecLabels on
the first call.

>>> There are a few other problems. First, there's no psql support of any
>>> kind. Now, this is kind of a corner-case feature: so maybe we don't
>>> really need it. And as I mentioned on another thread, there aren't a
>>> lot of good letters left for backslash-d commands. So I'd be just as
>>> happy to add a system view along the lines I previously proposed for
>>> comments and call it good. Alternatively, or in addition, we could
>>> add a \d command after all. The best way forward is debatable, but we
>>> certainly need *something*, because interpreting the pg_seclabel
>>> catalog by hand is not for the faint of heart.
>>
>> Do you suggest the new system views should be defined for each supported
>> object classes, such as pg_largeobject_seclabel? It seems to me a bit
>> inflation of number of system views.
>> My preference is psql's \d commands at first.
>
> Please see http://archives.postgresql.org/pgsql-hackers/2010-09/msg01080.php
>
OK, I'll emulate this approach at first.

Thanks,
--
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>