[PATCH] SE-PgSQL/lite (r2429)
От | KaiGai Kohei |
---|---|
Тема | [PATCH] SE-PgSQL/lite (r2429) |
Дата | |
Msg-id | 4AFCC0A5.8090103@ak.jp.nec.com обсуждение исходный текст |
Ответы |
Re: [PATCH] SE-PgSQL/lite (r2429)
[PATCH] SE-PgSQL/lite (r2451) |
Список | pgsql-hackers |
The attached patch is a "lite" version of SE-PostgreSQL, for the CommitFest#3. Its characteristic changes from the previous patches are developer documentations and slimed-up code. The developer documentation is a suggestion on the last commit fest. In the CF#2, we worked to implement a common abstraction layer for both of DAC and MAC, but its change set got larger than we expected at the begining. Then, we decided to implement them with deployment of hooks on the strategic points with clear documentation. The src/backend/security/sepgsql/README is a documentation from the viewpoint of developers. I belive it can help to understand intention of the SE-PgSQL design. In addition, I paid much efforts to write source code comments to introduce the purpose and its requirement. See the: http://code.google.com/p/sepgsql/source/browse/trunk/sepgsql/src/backend/security/sepgsql/README The scale of change set has been a headache for us. Some quantity of change set is unavoidable to implement access controls on comprehensive database objects. For example, the catalog/aclchk.c and utils/adt/acl.c have more than 9,000 lines in total. In the v8.4 development cycle, I got a suggestion to reduce a burden of reviewer to split off a few functionalities, such as "security_context" system column and row-level access controls. In this patch, I splited off a few functionalities furthermore. It does not apply any access controls except for four types of database objects classes; databases, schemas, tables and columns. We can incrementally implement access controls on the rest of database objects, such as procedures, in the future. In addition, I also splited off a few features. Now it has no special feature to manage security context. It is stored within a certain text field of system catalogs related to the four object types. Now it has no access control decision cache which contributes abour 800 lines of code reduction. In total, this patch contains about 9.5KL of change set. - About 2.1KL for documentaions (doc/src/sgml/* and the README). - About 1.7KL for test cases (src/test/*). - Rest of 5.5KL are as follows: - About 3.3KL for SE-PgSQL specific code with comments. (include/security/* and backend/security/*) - About 0.6KL for headers. - About 1.2KL for core routines. - About 0.3KL for pg_dump and initdb (bin/*) You might feel the 3.3KL is still a bit large. But its reason is obvious in the source code. I paid much efforts to describe source code comments to help understand the purpose and intention of the functions. About half of the 1.2KL is due to the statement support to give an explicit security context on CREATE or ALTER statement. But these are commonly-used code, implemented such as: rel = heap_open(RelationRelationId, RowExclusiveLock); : value[Anum_pg_class_relsecon - 1] = CStringGetTextDatum(relsecon); : simple_heap_update(rel, &newtuple->t_self, newtuple); : heap_close(rel); I don't think it is a major hurdle for reviewing. So, all we need to pay great attention is the rest of 0.6KL. I think it is enough small change set as long as SE-PgSQL does not lose its soul. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.nec.com>
Вложения
В списке pgsql-hackers по дате отправления:
Следующее
От: Greg SmithДата:
Сообщение: Re: write ahead logging in standby (streaming replication)