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 →
-
pgindent run for 9.0, second run
- 239d769e7e05 9.0.0 cited
Attachments
- sepgsql-v9.1-lite.1.patch (application/octect-stream) patch v9
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>