Re: Updates of SE-PostgreSQL 8.4devel patches (r1268)

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 02:04:00
Message-ID: 4941C690.60803@ak.jp.nec.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

KaiGai Kohei wrote:
> 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.

In addition,

- The new security conlumn has common name for each security mechanisms.
Candidates are "security_attr", "security_attribute", "sec_attr" or
"security". At first, I start it with "security_attr".

> - 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>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2008-12-12 02:12:50 Re: benchmarking the query planner
Previous Message Tom Lane 2008-12-12 02:03:27 Re: Mostly Harmless: Welcoming our C++ friends