Itagaki Takahiro wrote: > KaiGai Kohei <kai...@kaigai.gr.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 <kai...@ak.jp.nec.com> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
