Re: Updates of SE-PostgreSQL 8.4devel patches (r1168)
От | Bruce Momjian |
---|---|
Тема | Re: Updates of SE-PostgreSQL 8.4devel patches (r1168) |
Дата | |
Msg-id | 200811031930.mA3JU1E16542@momjian.us обсуждение исходный текст |
Ответ на | Re: Updates of SE-PostgreSQL 8.4devel patches (r1168) (KaiGai Kohei <kaigai@kaigai.gr.jp>) |
Ответы |
Re: Updates of SE-PostgreSQL 8.4devel patches (r1168)
(KaiGai Kohei <kaigai@ak.jp.nec.com>)
|
Список | pgsql-hackers |
KaiGai Kohei wrote: > > I just looked over the patch. This new version with row-level SQL > > security has certainly reduced the SE-Linux-specific part, which is > > good. > > > > It was interesting how you implemented SQL-level column-level > > permissions: > > > > CREATE TABLE customer ( > > cid integer primary key, > > cname varchar(32), > > credit varchar(32) SECURITY_CONTEXT = 'system_u:object_r:sepgsql_secret_table_t' > > ); > > > > I am unclear how that will behave with the column-level permissions > > patch someone is working on. I am wondering if your approach is clearer > > than the other patch because it gives a consistent right policy for rows > > and columns. > > The column-level permissions in SE-PostgreSQL works independently and > orthogonally from the upcoming column-level permissions by Stephen Frost. > When the SE-PostgreSQL is enabled, both of facilities have to allow the > client to access required columns. > > In the above case, the "credit" column has "sepgsql_secret_table_t" type, > but rest of columns inherits the type of "customer" table which allows > non-administrative users to access in the default security policy. > If the given query contains the "credit" column, SE-PostgreSQL checks > privileges of client to access columns labeled as "sepgsql_secret_table_t", > then it raises an error to abort the current transaction if the security > policy does not allow it. > > There is a possibility that column-level ACLs are set via newer GRANT/REVOKE > statement. In this case, the core PostgreSQL checks them, and raises an error > if violated. OK. I am wondering if we _want_ two ways to set column permisions, especially since I think there will be only one way to set row-level permissions. > > I was wondering why you mention the NSA (U.S. National Security Agency) > > in the patch? > > > > +# NSA SELinux support > > The original author of SELinux is NSA. > There is no more meanings than a caption of the option. > I'll fix it, if necessary. Yes, please remove; the "NSA" suggests to me that this is an NSA-only feature, which it is not; it was just originally designed for them. > > The size of the patch is still larger but I don't see any way to reduce it: > > > > 1275 sepostgresql-docs-8.4devel-3-r1168.patch > > 625 sepostgresql-pg_dump-8.4devel-3-r1168.patch > > 829 sepostgresql-policy-8.4devel-3-r1168.patch > > 1736 sepostgresql-row_acl-8.4devel-3-r1168.patch > > 10847 sepostgresql-sepgsql-8.4devel-3-r1168.patch > > 1567 sepostgresql-tests-8.4devel-3-r1168.patch > > 16879 total > > I thought the "sepostgresql-docs" can be replaced by the pointing to the wiki > page, how do you think the idea? No, I docs for using the tarball should be in the main documentation, even if they are not compile-enabled by default. The new patch affects the main Postgres backend code much less, which is a great improvement. -- 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 по дате отправления:
Предыдущее
От: Alvaro HerreraДата:
Сообщение: Re: Re: [COMMITTERS] pgsql: Rework subtransaction commit protocol for hot standby.