Re: Updates of SE-PostgreSQL 8.4devel patches (r1197)
От | Simon Riggs |
---|---|
Тема | Re: Updates of SE-PostgreSQL 8.4devel patches (r1197) |
Дата | |
Msg-id | 1226667942.27904.568.camel@ebony.2ndQuadrant обсуждение исходный текст |
Ответ на | Re: Updates of SE-PostgreSQL 8.4devel patches (r1197) (KaiGai Kohei <kaigai@ak.jp.nec.com>) |
Ответы |
Re: Updates of SE-PostgreSQL 8.4devel patches (r1197)
|
Список | pgsql-hackers |
On Thu, 2008-11-13 at 10:44 +0900, KaiGai Kohei wrote: > It's unclear for me what is the point you said. > I guess you concern the fixed length field is always allocated in > the case when any security feature is not enabled also, or performance > degradation on the large scale databases. > If incorrect, please tell me in another expression. > > At first, the fixed length 4 byte field is allocated only when > the SE-PostgreSQL (or other security feature) is enabled. It can be > controlled via PGACE hook. The pgaceSecurityAttributeNecessary() can > return bool value, and it indicates the necessity of the security > field. If SE-PostgreSQL is disabled on compile-time or run-time, > the fixed length 4 byte value is not allocated. I'm sorry for not making my thoughts clearer. Let me try again: As I understand it, when enabled, the overhead for each row is more than 4 bytes because you include a text field also, which you say has a restricted number of values. IMHO the overhead is unacceptable, given that our row overhead is already high. I would prefer to make the maximum overhead per row 4 bytes only, which matches the maximum number of required labels. This will allow very large databases to use this feature. 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. -- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support
В списке pgsql-hackers по дате отправления: