sepgsql contrib module

Kouhei Kaigai <kaigai@ak.jp.nec.com>

From: KaiGai Kohei <kaigai@ak.jp.nec.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: KaiGai Kohei <kaigai@kaigai.gr.jp>, PgHacker <pgsql-hackers@postgresql.org>
Date: 2010-12-24T02:53:25Z
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

Attachments

The attached patch is the modular version of SE-PostgreSQL.

Since I reduced the caching mechanism for access control decision,
its code scale became about 2.6KL.

[kaigai@saba sepgsql]$ wc -l *.[ch]
  353 dml.c
  366 hooks.c
  477 label.c
  158 proc.c
  267 relation.c
   98 schema.c
  617 selinux.c
  287 sepgsql.h
 2623 total

In addition, *.sgml file uses about 300 lines.


There is one another issue to be discussed.
We need a special form of regression test. Because SE-PostgreSQL
makes access control decision based on security label of the peer
process, we need to switch psql process during regression test.
(So, I don't include test cases yet.)

We have 'runcon' command to launch a child process with specified
security label as long as the security policy allows. If we could
launch 'psql' by 'runcon' with specified label, we can describe
test-cases on the existing framework on 'make installcheck'.

An idea is to add an option to pg_regress to launch psql command
with a specified wrapper program (like 'runcon').
In this case, each contrib modules kicks with REGRESS_OPTS setting.
One thing to be considered is the security label to be given to
the 'runcon' is flexible for each *.sql files.

Thanks,
-- 
KaiGai Kohei <kaigai@ak.jp.nec.com>