Re: security label support, revised

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...

>> 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.

>> 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

> Right now, I don't have any complaint about the patch to the backend
> you revised, so I'd like to submit the next patch as an incremental
> one to the seclabel-v4.patch, except for src/bin/pg_dump.

Yes, an incremental diff would be preferable, thanks.

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