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

On Sun, 2008-11-16 at 01:40 +0900, KaiGai Kohei wrote:

> I had two reasons why I didn't implement the option.
>
> The first is the relationship between table/column-level access controls
> and row-level controls on system catalogs is unclear.
> For example, SE-PostgreSQL handles DELETE on pg_class as an operation to
> drop table, because it has same meanings. The table-level access controls
> break down, if only row-level checks are disabled.

If pg_class needs a special case, no problem.

> 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?

I'm sure the problem is solvable. If you just formed the tuple you
probably know enough about a table to get security context. If not,
perhaps security context would be assigned/checked at a lower level.

It was designed with the security community in mind, but it would be
great if it can work for more people. Please could you look to see if
this is possible?

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.

--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support