Re: Updates of SE-PostgreSQL 8.4devel patches
От | Bruce Momjian |
---|---|
Тема | Re: Updates of SE-PostgreSQL 8.4devel patches |
Дата | |
Msg-id | 200809241929.m8OJTXl08524@momjian.us обсуждение исходный текст |
Ответ на | Updates of SE-PostgreSQL 8.4devel patches (KaiGai Kohei <kaigai@ak.jp.nec.com>) |
Ответы |
Re: Updates of SE-PostgreSQL 8.4devel patches
(KaiGai Kohei <kaigai@ak.jp.nec.com>)
|
Список | pgsql-hackers |
KaiGai Kohei wrote: > I updated the series of patches for SE-PostgreSQL 8.4devel. > > [1/5] http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r1043.patch > [2/5] http://sepgsql.googlecode.com/files/sepostgresql-pg_dump-8.4devel-3-r1043.patch > [3/5] http://sepgsql.googlecode.com/files/sepostgresql-policy-8.4devel-3-r1043.patch > [4/5] http://sepgsql.googlecode.com/files/sepostgresql-docs-8.4devel-3-r1043.patch > [5/5] http://sepgsql.googlecode.com/files/sepostgresql-tests-8.4devel-3-r1043.patch I looked over the patches listed above. They have line counts listed below: 10759 sepostgresql-sepgsql-8.4devel-3-r1043.patch 616 sepostgresql-pg_dump-8.4devel-3-r1043.patch 826 sepostgresql-policy-8.4devel-3-r1043.patch 1237 sepostgresql-docs-8.4devel-3-r1043.patch 836 sepostgresql-tests-8.4devel-3-r1043.patch 14274 total Particularly interesting was the doc patch, sepostgresql-docs-8.4devel-3-r1043.patch. It explains how SE-PostgreSQL checks the permission level of the client process (getpeercon) and uses that to determine what the user should see. Also interesting is how a new row-level system permission column references a new table 'pg_security', which holds security credentials for the row. The bulk of the patch is in sepostgresql-sepgsql-8.4devel-3-r1043.patch, which modifies the backend. About 30% of it or 3k lines modify our backend, and the rest are indepdendent support routines in their own C files. So, I am now reevaluating how we should proceed with this patch. I think we know we want column-level permissions and that is being worked on, so it should reduce the size of the 3k part of that patch slightly. As far as backend changes the largest part is the row-level permissions. Do we want row-level permissions to be accessible at the SQL level, perhaps optionally, by having a role be associated with a row, and only role members can see it. If we do, and implement it, the 3k part is reduced significantly. FYI, SE-PostgreSQL sets _row_ permissions by assigning to the new permissions system column: INSERT INTO drink (security_context, id, name, price)VALUES('system_u:object_r:sepgsql_table_t:SystemHigh', 7, 'tea', 130); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ That string is what is placed in 'pg_security' and a reference to is placed on the row. The other conclusion I came to is that the other 11k of patch is really independent SE-Linux interface code and not likely to change in size no matter what we implement at the SQL level. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
В списке pgsql-hackers по дате отправления:
Следующее
От: Heikki LinnakangasДата:
Сообщение: Re: pgsql: Make LC_COLLATE and LC_CTYPE database-level settings.