Jaime Casanova wrote:
> On Mon, Feb 16, 2009 at 12:18 PM, Robert Haas <robertmhaas@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 <kaigai@ak.jp.nec.com>