On Mon, Feb 16, 2009 at 10:59 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@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).
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers