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

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: Updates of SE-PostgreSQL 8.4devel patches (r1268)
Дата
Msg-id 200812110539.mBB5dIv02448@momjian.us
обсуждение исходный текст
Ответ на Re: Updates of SE-PostgreSQL 8.4devel patches (r1268)  (Bruce Momjian <bruce@momjian.us>)
Ответы 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>)
Список 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 по дате отправления:

Предыдущее
От: ITAGAKI Takahiro
Дата:
Сообщение: build failure in pgevent
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Updates of SE-PostgreSQL 8.4devel patches (r1268)