Re: Updates of SE-PostgreSQL 8.4devel patches (r1268)

From: "Robert Haas" <robertmhaas(at)gmail(dot)com>
To: "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>
Cc: "KaiGai Kohei" <kaigai(at)kaigai(dot)gr(dot)jp>, "Peter Eisentraut" <peter_e(at)gmx(dot)net>, "KaiGai Kohei" <kaigai(at)ak(dot)jp(dot)nec(dot)com>, pgsql-hackers(at)postgresql(dot)org, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Bruce Momjian" <bruce(at)momjian(dot)us>
Subject: Re: Updates of SE-PostgreSQL 8.4devel patches (r1268)
Date: 2008-12-12 17:17:52
Message-ID: 603c8f070812120917w41d882d3w435915256d67c45@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>> Peter made an excellent point a few emails upthread: there seemed to
>> be consensus in the September CommitFest that we needed SQL-level
>> support for row and column level security before we talked about
>> implementing those features as part of SELinux. I don't see that
>> we're any closer to that goal than we were then. There has been some
>> progress made on column-level permissions, but the patch is back in
>> "waiting for author" limbo, and the only alternatives for SQL-level
>> row-level permissions is to have them INSTEAD OF SELinux-based
>> row-level permissions.
>
> I don't understand -- why wouldn't we just have two columns, one for
> plain row-level security and another for whatever security system the
> platforms happens to offer? If we were to follow that route, we could
> have row-level security first, extracting the feature from the current
> patch; and the rest of PGACE could be a much smaller patch implementing
> the rest of the stuff, with SELinux support for now with an eye to
> implementing Solaris TX or whatever.

Well, I think we should do exactly what you're proposing, so don't ask me.

...Robert

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Grittner 2008-12-12 17:27:59 Re: benchmarking the query planner
Previous Message Simon Riggs 2008-12-12 17:09:57 Re: benchmarking the query planner