Jaime Casanova wrote:
On Tue, Jan 27, 2009 at 2:18 PM, Tom Lane <t...@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.8030...@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 <kai...@ak.jp.nec.com>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
