Re: How to get SE-PostgreSQL acceptable

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>, Bruce Momjian <bruce(at)momjian(dot)us>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Josh Berkus <josh(at)agliodbs(dot)com>, Joshua Brindle <method(at)manicmethod(dot)com>, PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: How to get SE-PostgreSQL acceptable
Date: 2009-01-31 14:09:47
Message-ID: 603c8f070901310609x7a4e6e00yd877330afa98b35c@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Jan 31, 2009 at 8:32 AM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> * KaiGai Kohei (kaigai(at)kaigai(dot)gr(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2009-01-31 14:15:45 Re: pgevent warnings on mingw
Previous Message Andrew Dunstan 2009-01-31 14:07:50 pgevent warnings on mingw