Re: SE-PostgreSQL and row level security

On Mon, Feb 16, 2009 at 11:21 AM, Greg Stark <stark(at)enterprisedb(dot)com> wrote:
> On Mon, Feb 16, 2009 at 4:14 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>
>> I'm not sure I understand what you mean by that. I expect that if I
>> deny a particular user access to SELECT from a particular table the
>> system will throw a permissions error if that user later enters
>> "SELECT * FROM <table-name>". I don't expect that the system will
>> foresee every possible alternative way that a user might able to infer
>> something about the contents of that table and block it. I similarly
>> expect that if I install SE-PostgreSQL and configure it to filter out
>> certain rows from accesses to certain tables, those rows will in fact
>> be filtered. I still don't expect it to foresee every possible
>> alternative way that a user might be able to infer something about the
>> contents of the data to which the user does not have direct access.
>>
>> Is this fundamentally a semantic issue? If there's an asymmetry here
>> in what is being claimed, I'm not seeing it.
>
> Well the asymmetry is that in the former case the verb is "deny" and
> the latter it's "filter"...

Oh. Somehow I have a hard time getting worked up about that. It
seems like a trivial concession to ease of use. Otherwise, a query
with 12 joins will need to have 13 additional clauses explicitly
appended to the WHERE clause to prevent errors, and I'm not sure what
that really buys you. Surely I'm never going to intentionally write a
query that doesn't include the relevant permissions-based exclusion,
since otherwise my queries will blow up in my face.

I'm a little bothered by this issue with respect to INSERT, UPDATE,
and DELETE, since it's possible that I have permission to see rows but
not updated them, and it would be a little weird if select and update
with equivalent where clauses operated on different sets of records
(although that can happen anyway, because of BEFORE triggers, and it's
pretty irritating). It's not clear that there's a clean solution
here, but it's at least food for thought.

But for SELECT it just seems like nuisance value.

...Robert