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

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>, KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Updates of SE-PostgreSQL 8.4devel patches (r1268)
Date: 2008-12-11 05:39:18
Message-ID: 200812110539.mBB5dIv02448@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Bruce Momjian wrote:
> KaiGai Kohei wrote:
> > >> CREATE TABLE t (
> > >> a int,
> > >> b text
> > >> ) WITH (ROW_LEVEL_ACL=ON);

Let me outline the simplest API, assuming we are using table-level
granularity for the security columns.

CREATE TABLE would support

WITH (ROWACL = TRUE/FALSE);

for row-level acl and:

WITH (SECEXT = TRUE/FALSE);

for SE-Linux, with 'SECEXTL' standing for SECurity EXTernal or
SECurity_contEXT.

And then in postgresql.conf we would have:

default_with_rowacl

and

default_with_secext

which would control the default value of ROWACL and SECEXT when CREATE
TABLE does not specify these values. This is how OIDs works now.

When SE-Linux is enabled, CREATE TABLE would issue an error if SECEXT
was false. I can't think of a clean way to guarantee that existing
tables have SECEXT though, which means we might need to have a missing
'security_context' column mean default SE-Linux permissions.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2008-12-11 05:43:24 Re: Updates of SE-PostgreSQL 8.4devel patches (r1268)
Previous Message ITAGAKI Takahiro 2008-12-11 05:19:00 build failure in pgevent