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

From: KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>, Bruce Momjian <bruce(at)momjian(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Updates of SE-PostgreSQL 8.4devel patches (r1197)
Date: 2008-11-18 02:51:20
Message-ID: 49222DA8.1090909@ak.jp.nec.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)ak(dot)jp(dot)nec(dot)com>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2008-11-18 03:08:26 Re: Synchronous replication patch v2
Previous Message Emmanuel Cecchet 2008-11-18 02:00:03 Re: Transactions and temp tables