Re: SE-PgSQL patch review

From: KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>
To: Itagaki Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>
Cc: KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: SE-PgSQL patch review
Date: 2009-11-30 06:40:30
Message-ID: 4B1368DE.2000506@ak.jp.nec.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Itagaki Takahiro wrote:
> KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp> wrote:
>> -- keep it smaller, and step-by-step enhancement
>
> I'd prefer "smaller concept" rather than "smaller patch".

For the last a few days, I've talked with Itagaki-san off list to make clear
where is the point of his suggestion.

In summary, it was similar approach with what I already proposed in the CF#2,
but rejected.

During the first commit-fest of v8.5 development cycle, Stephen Frost suggested
to rework the default PG's access controls to host other optional security
features, not only the default one.
Then, I submitted a large patch titled as "Reworks for Access Controls",
but it contained 3.5KL of changeset on the core routines, and 4KL of new codes
into "src/backend/security/*" except for documentations and testcases.
Then, this approach was rejected (not "returned with feedback") due to the scale
and complexity.

After the fest, we discussed the direction to implement SE-PgSQL.
Basically, it needs to keep the changeset small, and the rest of features (such
as row-level granurality, access control decision cache, ...) shoule be added
step-by-step consistently, according to the suggestion in the v8.4 development
cycle. Heikki Linnakangas also suggested we need developer documentation which
introduces SE-PgSQL compliant permission checks and specification of security
hooks, after the reworks are rejected.

So, I boldly removed most of the features from SE-PgSQL except for its core
functionalities, and added developer documentation (README) and widespread
source code comments to introduce the implementations instead.
In the result, the current proposal is near to naked one.
- No access controls except for database, schema, table and column.
- No row-level granularity in access controls.
- No access control decision chache.
- No security OID within HeapTupleHeader.

I believe the current patch is designed according to the past suggestions.
However, his suggestion seems to me backing to the rejected approach again.

I've been torn between the past suggestions and his suggestion.
So, I asked him to get off reviewing the patch, because of the deadlock in
the development process. At the current moment, I'd like to respect
suggestions in the past discussions more.

Thanks for paying your efforts in spite of differences in opinions.
--
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 Craig Ringer 2009-11-30 06:55:11 Re: draft RFC: concept for partial, wal-based replication
Previous Message Itagaki Takahiro 2009-11-30 05:38:59 Re: New VACUUM FULL