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 04:10:18
Message-ID: 4922402A.5020808@ak.jp.nec.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

In addition, I want you to make clear the priority of the facility.

We can disable row-level access control factually with uniformed
security context which allows client any kind of accesses.
In this case, all tuples shares a single text representation,
so the size of external text representation is enough small to
ignore.

I guess you concerned the per-tuple security attribute because
it has 1:1 mapped text representation on pg_security.
However, it is incorrect.
I don't think we should give high priority for the feature to
kill per-tuple security attribute now.

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 Simon Riggs 2008-11-18 05:27:38 Re: Updates of SE-PostgreSQL 8.4devel patches (r1197)
Previous Message Bruce Momjian 2008-11-18 03:51:39 Re: Re: [BUGS] libpq does not manage SSL callbacks properly when other libraries are involved.