Jaime Casanova wrote:
> On Tue, Jan 27, 2009 at 2:18 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> This seems to me to be exactly parallel to deciding that SELinux should
>> control only table/column permissions within SQL; an approach that would
>> be enormously less controversial, less expensive, and more reliable than
>> what SEPostgres tries to do.
>>
>
> seems that the controversial part of sepgsql is row level permissions,
> can we try to commit (obviously with good revision and test) the
> table/column privileges part of that patch?
Actually, it is already done.
http://code.google.com/p/sepgsql/source/browse/trunk/sepgsql/src/backend/utils/misc/guc.c#1242
http://code.google.com/p/sepgsql/source/browse/trunk/sepgsql/src/backend/security/sepgsql/permissions.c#518
Its original purpose is different, to reduce storage consumption.
But it can be a point of compromise.
See, http://archives.postgresql.org/message-id/492691A8.8030103@ak.jp.nec.com
Is it a reasonable option to allow users to turn on/off?
I can add a documentation about its background and tradeoffs,
for user's correct decision.
Thanks,
> that is still a step on the direction of full centralized security
> management on the system...
>
> let the row level privileges part for 8.5, that way the patch will be
> smaller now and then...
>
> remember, postponed is not rejected is just a way to give more time to
> think (WITH patch comes from the prior release cycle and was committed
> in this release), not to think about one scenario but about all
> possible scenarios in a more wide audience
--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>
