Horton

Re: sepgsql contrib module

Kohei KaiGai <kaigai@kaigai.gr.jp>

View thread
From: KaiGai Kohei <kaigai@kaigai.gr.jp>
To: Simon Riggs <simon@2ndQuadrant.com>
Cc: KaiGai Kohei <kaigai@ak.jp.nec.com>, Robert Haas <robertmhaas@gmail.com>, PgHacker <pgsql-hackers@postgresql.org>
Date: 2010-12-30T00:26:07Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. pgindent run for 9.0, second run

(2010/12/27 17:53), Simon Riggs wrote:
> On Fri, 2010-12-24 at 11:53 +0900, KaiGai Kohei wrote:
>
>> The attached patch is the modular version of SE-PostgreSQL.
>
> Looks interesting.
>
> Couple of thoughts...
>
> Docs don't mention row-level security. If we don't have it, I think we
> should say that clearly.
>
Indeed, it is a good idea the document mentions what features are not
implemented in this version clearly, not only row-level security, but
DDL permissions and so on. I'd like to revise it soon.

> I think we need a "Guide to Security Labels" section in the docs. Very
> soon, because its hard to know what is being delivered and what is not.
>
Does it describe what is security label and the purpose of them?
OK, I'd like to add this section here.

> Is the pg_seclabel table secure? Looks like the labels will be available
> to read.
>
If we want to control visibility of each labels, we need row-level
granularity here.

> How do we tell if sepgsql is installed?
>
Check existence of GUC variables of sepgsql.*.

> What happens if someone alters the configuration so that the sepgsql
> plugin is no longer installed. Does the hidden data become visible?
>
Yes. If sepgsql plugin is uninstalled, the hidden data become visible.
But no matter. Since only a person who is allowed to edit postgresql.conf
can uninstall it, we cannot uninstall it in run-time.
(An exception is loading a malicious module, but we will be able to
hook this operation in the future version.)

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