On Thu, May 24, 2012 at 12:00 PM, Kohei KaiGai <kai...@kaigai.gr.jp> wrote: >> Another issue, BTW, are FOREIGN KEY constraints. Should you be allowed to >> created references to rows which are invisible to you, or should FOREIGN KEY >> constraints be exempt from security policies? I'd say they shouldn't be, i.e. >> the policy WHERE clause should be added to constraint checking queries like >> usual. But maybe I'm missing some reason why that'd be undesirable… >> > I agree. The row level security policy should not be applied during FK checks > (or other internal stuff; to be harmless). At the previous discussion, it was > issued that iteration of FK/PK proving enables malicious one to estimate > existence of invisible tuple and its key value, although they cannot see the > actual values. It is well documented limitation, thus, user should not use > row- > level security (or should not use natural key) if they cannot accept > this limitation.
You say "I agree", but it seems to me that you and Florian are in fact taking opposite positions. FWIW, I'm inclined to think that you should NOT be able to create a row that references an invisible row. You might end up with that situation anyway, because we don't know what the semantics of the security policy are: rows might become visible or invisible after the fact, and we can't police that. But I think that if you take the opposite position that the select queries inside fkey triggers ought to be exempt from security policy, then you need to build some new mechanism to make that happen, which seems like extra work for no benefit. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers