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

On Tue, 2008-11-18 at 11:51 +0900, KaiGai Kohei wrote:
> 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.

We manage to include a NULL bitmap without doing this.

The hasoids option seems to be unused on most of those call points. How
many of those call points would need security context?

The change you suggest looks possible, so maybe it is the way, but it
also looks fairly ugly already. If we did this it would not be by adding
another bool, but by adding an options object.

Another way would be to include a security context in all newly created
tuples, but remove it during heap_update, heap_insert etc if it is
unused by the relation. That seems more straightforward.

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

SUSE?

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