From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Gregory Stark <stark(at)enterprisedb(dot)com>, KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>, Martijn van Oosterhout <kleptog(at)svana(dot)org>, bogdan(at)omnidatagrup(dot)ro, David Fetter <david(at)fetter(dot)org>, KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: SE-PostgreSQL and row level security |
Date: | 2009-02-16 15:59:38 |
Message-ID: | 17345.1234799978@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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).
> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Laurent Laborde | 2009-02-16 16:01:56 | Re: pg_restore --multi-thread |
Previous Message | Tom Lane | 2009-02-16 15:48:44 | Re: Questions about parsing boolean and casting to anyelement |