Re: SE-PostgreSQL and row level security

On Mon, Feb 16, 2009 at 10:59 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> 2. Foreign-key constraints.
>> (A) If you have update or delete privileges on a table that is
>> referenced by foreign keys, you might be able to infer the existence
>> of a hidden, referring row because your update or delete fails.
>
> Also the other direction (insert or update on the referencing table
> lets you infer contents of the referenced table).

Ah, right.

>> Is there anything else?
>
> If we ever had SQL-spec ASSERTIONS, they'd create hard-to-analyze
> issues of this sort. I've also seen people abuse CHECK constraints
> in ways that expose data cross-row (they shouldn't do so, but...)

I can imagine someone doing that. :-(

>> Also, don't problems 2(A) and 2(B) already exist with just table-level
>> DAC? What happens today if you give permission on the referring table
>> but not the referred-to table, or the other way around?
>
> I'm repeating myself, but: the reason it isn't a problem now is that
> plain SQL doesn't claim to be able to hide the existence of data.

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.

...Robert