(2010/09/27 11:49), Robert Haas wrote:
On Sat, Sep 25, 2010 at 7:04 AM, KaiGai Kohei<kai...@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 <kai...@kaigai.gr.jp> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
