Jaime Casanova wrote:
On Mon, Feb 16, 2009 at 12:18 PM, Robert Haas <robertmh...@gmail.com> wrote:
With reference to row-level security, most of the complaining about
this feature has been along the lines of "I don't like the idea that
rows get filtered from my result-set that I didn't ask to have
filtered".
yeah! because was filtered by powers above yours... ;)
i thing row level acl it's good feature for those that *really* need
it, as every other solution this is not for everyone and could and
will be misused sometimes... as far as the code maintain readibility
and doesn't interfer in an instalation that doesn't include
--enable-selinux i'm in favor of including it...
If patched PostgreSQL binary, you can turn on row level acls with
a table option: row_level_acl=[on|off], independent from a compile
time option: --enable-selinux.
It was suggested on earlier phase that compile time option should
be used to avoid build dependency issues, so I removed the compile
option to turn on/off row level acl.
To me, the fact that you didn't have to ask seems like a
huge convenience, and I can't imagine why you'd want it otherwise.
Sure, the behavior needs to be documented, but that doesn't seem like
a big deal.
not only a convenience, it's a way to enforce policies that cannot be
circumvented easily from programming (if you have very secret info
that cost a lot, you can start being paranoic even of your own
developing team ;)
In generally, from the viewpoint of security, it is not a good design
to check permissions in many places, and depending on all them are
implemented correctly.
We should not assume users/applications always gives correct queries.
Thanks,
--
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
