Robert Haas <robertmh...@gmail.com> wrote: > Tom Lane <t...@sss.pgh.pa.us> wrote: >> Robert Haas <robertmh...@gmail.com> writes:
>>> IMHO, this new feature should be similarly simple: when an >>> unprivileged user references a table, treat that as a reference >>> to a leakproof view over the table, with the RLS qual injected >>> into the view. >> >> And for insert/update/delete, we do what exactly? > > The same mechanism will prevent UPDATE and DELETE from seeing any > rows the user shouldn't be able to touch. +1 > Simon and Greg are arguing that when an INSERT or UPDATE happens, > we ought to also check that the NEW row matches the RLS qual. I > don't find that to be terribly important because you can > accomplish the same thing with a per-row trigger today; and I > also don't think everyone will want that behavior. As an example from my Wisconsin Courts days, source documents come in which need to be entered, which may contain a Social Security Number, and most of the Clerk of Courts staff should be authorized to enter that into the database. Once it is entered, most people should not be allowed to view it, including many of the people who were authorized to enter it initially. It's one thing for a line staff person to have a handful of documents come across their desk with SSN on a given day; it's quite another if they could dump a list of names, addresses, dates of birth, and SSNs for the entire database on demand. In a way this issue is similar to the covert channel issue -- volume matters. -- Kevin Grittner EDB: 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