Re: Updates of SE-PostgreSQL 8.4devel patches (r1268) - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Updates of SE-PostgreSQL 8.4devel patches (r1268)
Date
Msg-id 200812110539.mBB5dIv02448@momjian.us
Whole thread Raw
In response to Re: Updates of SE-PostgreSQL 8.4devel patches (r1268)  (Bruce Momjian <bruce@momjian.us>)
Responses Re: Updates of SE-PostgreSQL 8.4devel patches (r1268)  (Bruce Momjian <bruce@momjian.us>)
Re: Updates of SE-PostgreSQL 8.4devel patches (r1268)  (KaiGai Kohei <kaigai@kaigai.gr.jp>)
Re: Updates of SE-PostgreSQL 8.4devel patches (r1268)  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +


pgsql-hackers by date:

Previous
From: ITAGAKI Takahiro
Date:
Subject: build failure in pgevent
Next
From: Bruce Momjian
Date:
Subject: Re: Updates of SE-PostgreSQL 8.4devel patches (r1268)