Re: SE-PostgreSQL and row level security - Mailing list pgsql-hackers

From Tom Lane
Subject Re: SE-PostgreSQL and row level security
Date
Msg-id 17345.1234799978@sss.pgh.pa.us
Whole thread Raw
In response to Re: SE-PostgreSQL and row level security  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: SE-PostgreSQL and row level security
List pgsql-hackers
Robert Haas <robertmhaas@gmail.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).

> 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...)

> 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.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Questions about parsing boolean and casting to anyelement
Next
From: Laurent Laborde
Date:
Subject: Re: pg_restore --multi-thread