Re: Updates of SE-PostgreSQL 8.4devel patches (r1197)
От | KaiGai Kohei |
---|---|
Тема | Re: Updates of SE-PostgreSQL 8.4devel patches (r1197) |
Дата | |
Msg-id | 491EFB8A.7000009@kaigai.gr.jp обсуждение исходный текст |
Ответ на | Re: Updates of SE-PostgreSQL 8.4devel patches (r1197) (Simon Riggs <simon@2ndQuadrant.com>) |
Ответы |
Re: Updates of SE-PostgreSQL 8.4devel patches (r1197)
(Simon Riggs <simon@2ndQuadrant.com>)
|
Список | pgsql-hackers |
Simon Riggs wrote: >>> I would also like to see the feature part of normal Postgres, rather >>> than as a compile time option. The per-row overhead would then be >>> optional, just as WITH OIDS is optional. This would allow many >>> applications to take advantage of row level security, without the need >>> for switching to a different executable and without the need to enable >>> it for every table. For high security applications, default_row_security >>> = on would obviously be a requirement. With a single executable on all >>> distros we will have more robust software and it will be easier to >>> configure and use. >> An issue is who can enable or disable the row-level security option. >> If the owner of table can do it discretionary, we don't call it a >> "mandatory" access control feature. > > It seems fairly easy to do that with a GUC, or at least an option on > CREATE DATABASE, with no equivalent ALTER DATABASE option. Once created > with security, a table would not be able to turn off security. So nobody > would be able to turn off security for existing data. SE-PostgreSQL already has a GUC option to enable/disable the feature, so I don't think a GUC option to control features is not a strange idea. In fact, I also had considered an option to disable the row-level access control feature in the similar way, when I got a comment that platform independent row-level security is a prerequisite to merge SE-PostgreSQL. However, I made a decision to implement the "rowacl" feature, not a new GUC option to disable row-level security. I had two reasons why I didn't implement the option. The first is the relationship between table/column-level access controls and row-level controls on system catalogs is unclear. For example, SE-PostgreSQL handles DELETE on pg_class as an operation to drop table, because it has same meanings. The table-level access controls break down, if only row-level checks are disabled. The other is an issue on implementation. Even if row-level security is disabled, tuples within pg_class, pg_attribute, pg_proc and pg_largeobject has to hold its security context, because it means the security context of tables, columns, procedure and largeobjects. However, the length of a tuple is computed at heap_form_tuple(), and its arguments don't contains the object id of relation. Thus, we cannot make a decision whether the newly created tuple should have a security field, or not. The heap_form_tuple() is invoked from 60 of functions. It might be possible to change all the argument list to deliver relation id. But it seems to me excess updates for the purpose. Thus, I recommend you to assign uniformed security context whole of the table. The default security policy allows all the clients to operate anything on tuples labeled as "sepgsql_table_t" except for relabeling them. (BTW, it is a default type when here is no special configuration.) Thanks, -- KaiGai Kohei <kaigai@kaigai.gr.jp>
В списке pgsql-hackers по дате отправления:
Предыдущее
От: Magnus HaganderДата:
Сообщение: Re: A error reported in patch "clientcert option for pg_hba"