Re: How to get SE-PostgreSQL acceptable
От | Robert Haas |
---|---|
Тема | Re: How to get SE-PostgreSQL acceptable |
Дата | |
Msg-id | 603c8f070901310609x7a4e6e00yd877330afa98b35c@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: How to get SE-PostgreSQL acceptable (Stephen Frost <sfrost@snowman.net>) |
Ответы |
Re: How to get SE-PostgreSQL acceptable
|
Список | pgsql-hackers |
On Sat, Jan 31, 2009 at 8:32 AM, Stephen Frost <sfrost@snowman.net> wrote: > * KaiGai Kohei (kaigai@kaigai.gr.jp) wrote: >> Stephen Frost wrote: >> > I think Bruce's question was where you stored the security_acl and >> > security_label columns. Based on your response (and a bit of purusal >> > through the code.google site), it looks like you still have security_acl >> > and security_label defined as internal columns and being included >> > for at least system tables (or is it everywhere?). >> >> In the current working tree, it (security id) is stored within >> padding field of HeapTupleHeader, so internal facility can read >> it via HeapTupleGetSecLabel(), but I already removed "security_acl" >> and "security_label" definition. >> Its basic structure is unchanged, the text form of security label >> is stored within pg_security system catalog. > > I'm pretty sure that structure is part of what people were unhappy about > though, and what makes it a much more invasive change that violates > certain levels in the system by requiring information at much lower > levels than it had before. IANAC, but that's my impression too. The simplified patch shouldn't assume that row-level security in its current form is going to end up getting put back in. AFAICS, there's no reason why the security ID for tables can't be a regular attribute in pg_class, or why the security attribute for columns can't be a regular attribute in pg_attribute. ...Robert
В списке pgsql-hackers по дате отправления: