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

Поиск
Список
Период
Сортировка
От KaiGai Kohei
Тема Re: Updates of SE-PostgreSQL 8.4devel patches (r1197)
Дата
Msg-id 49222DA8.1090909@ak.jp.nec.com
обсуждение исходный текст
Ответ на Re: Updates of SE-PostgreSQL 8.4devel patches (r1197)  (Simon Riggs <simon@2ndQuadrant.com>)
Ответы Re: Updates of SE-PostgreSQL 8.4devel patches (r1197)  (KaiGai Kohei <kaigai@ak.jp.nec.com>)
Re: Updates of SE-PostgreSQL 8.4devel patches (r1197)  (Simon Riggs <simon@2ndQuadrant.com>)
Список pgsql-hackers
Simon Riggs wrote:
>> The other is an issue on implementation. Even if row-level security is
>> disabled, tuples within pg_class, pg_attribute, pg_proc and pg_largeobject
>> has to hold its security context, because it means the security context of
>> tables, columns, procedure and largeobjects.
>> However, the length of a tuple is computed at heap_form_tuple(), and its
>> arguments don't contains the object id of relation. Thus, we cannot make
>> a decision whether the newly created tuple should have a security field, or
>> not. The heap_form_tuple() is invoked from 60 of functions. It might be
>> possible to change all the argument list to deliver relation id. But it
>> seems to me excess updates for the purpose.
> 
> WITH OIDS seems to work well without problem. Why is this different?

It is not a problem, but things which take a decision.

The heap_form_tuple() makes a new tuple according to the given
TupleDesc which has a bool variable of "tdhasoid".
This structure can be initialized at various functions. For example,
47 of functions invoke CreateTemplateTupleDesc() which requires an
argument of "bool hasoid".
If we follow the way of WITH OIDS, it will be necessary to modify
the declaration and 47 of invocations, at least.

I don't think your suggestion is a bad idea, except for the number
of modification on the core implementation.

> I think it will benefit everybody if this feature can work as an option
> of the main server. Currently, this feature seems to support only one
> configuration: a special build for SELinux on Red Hat. That's nice, but
> I want to see the patch open things up more for other distros/OS, plus
> options for people who don't want MAC, but do want row level security. 

This feature is not limited to Red Hat and related.

Some of distributions now provides SELinux option, but not a default.
I know Debian, Ubuntu, Gentoo and SuSE are doing.
Their default security policies are designed based on the upstreamed
SELinux policy which already has rules for SE-PostgreSQL. So, it will
be delivered to other distributions and enlarge its supporting platforms.

For other operating systems, I know Trusted Solaris folks have a plan
to implement their facilities on the PGACE security framework, at least.

My 6th patch (rowacl) provides a DAC based row-level security implementation.

Thanks,
-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Emmanuel Cecchet
Дата:
Сообщение: Re: Transactions and temp tables
Следующее
От: "Fujii Masao"
Дата:
Сообщение: Re: Synchronous replication patch v2