From: | KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Cc: | Gregory Stark <stark(at)enterprisedb(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <bruce(at)momjian(dot)us>, KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>, simon(at)2ndQuadrant(dot)com |
Subject: | Re: Updates of SE-PostgreSQL 8.4devel patches (r1268) |
Date: | 2008-12-12 01:59:25 |
Message-ID: | 4941C57D.8050702@ak.jp.nec.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I understood objections for "enable/disable something on compile-time"
approach. The following items are my revised proposal.
It does not conflicts to the policy Peter said before in this thread.
Items to be revised:
- It allows to compile multiple security mechanis within a single binary.
- It provides "--enable-selinux" configure option to build SELinux support,
but the Row-level ACLs is always built because it does not require any
platform specific libraries and so on.
- User choose one (or no) security mechanism on initdb and postmaster
starting up via $PGDATA/postgresql.conf. The current available options
are selinux, rowacl and nothing.
(*) What should be the default? rowacl? or, nothing?
The modified initdb interface is as follows:
$ initdb --pgace-security=(selinux|rowacl|nothing)
- It add a new system column for security purpose. It enables to store
a security attribute of tuple, so working security mechanism has to
handle it properly. For example, SE-PostgreSQL handles a tuple without
valid security context as a "unlabeled_t" tuple.
- The security mechanism can control whether the new tuple has its
security field, or not. If no security field is necessary, t_infomask
is not set HEAP_HASSECURITY bit, and it does not consume any additional
storage space.
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-12-12 02:03:27 | Re: Mostly Harmless: Welcoming our C++ friends |
Previous Message | Robert Haas | 2008-12-12 01:52:00 | Re: benchmarking the query planner |