row-level security (Dynamically rewrite queries)

Поиск
Список
Период
Сортировка
От Jonatan Evald Buus
Тема row-level security (Dynamically rewrite queries)
Дата
Msg-id 113ce31b0811200107n64ad7e6fm6dd88d44e047dc28@mail.gmail.com
обсуждение исходный текст
Ответы Re: row-level security (Dynamically rewrite queries)  (Richard Huxton <dev@archonet.com>)
Список pgsql-general
Hi there,
Is it possible to dynamically rewrite an SQL query for all operations (SELECT, INSERT, UPATE, DELETE etc.)?
It seems that using RULES it's possible to replace one query with another, but can the actual query that was executed by retrieved so it can be dynamically modified?
I.e. I'd like to create a rule along the lines of:
CREATE RULE txn_vpd ON
SELECT TO Transaction_Tbl
DO INSTEAD replace('WHERE', 'INNER JOIN User_Tbl ON Transaction_Tbl.userid = User_Tbl.id WHERE User_Tbl.name = \'CURRENT_USER\'', $SQL)
Where $SQL represents the actual SQL query that was executed on the table and the table has a column: userid which indicates the owner of the row.

Essentially what I'd like to do is implement row-level security (what Oracle calls "Virtual Private Database") but as far as I can find the last time this was discussed is several years ago and the general consensus ended up being "use veil".
Veil seems overly like an complicated approach for something that (in theroy) should be possible with a dynamic query rewrite using search and replace prior to execution.
Oracle's implementation seems quiete elegant for this, please see http://www.oracle.com/technology/pub/articles/10gdba/week14_10gdba.html or http://www.devshed.com/c/a/Oracle/RowLevel-Security-with-Virtual-Private-Database/ for examples.

One other approach that I could think of, would be to create a view for every table and use the view for accessing the data:
CREATE VIEW Transaction_Vw AS
SELECT * FROM Transaction_Tbl Txn
INNER JOIN User_Tbl U ON Txn.userid = U.id
WHERE U.name = 'CURRENT_USER'
However, can usage this view be enforced by the database by removing SELECT priviliges from Transaction_Tbl?
Also, I suspect that performance would go down the drain if complex joins are used? There could potentially be a lot of unnecessary joins to User_Tbl if multiple "secure view" where joined together.
Is the planner capable of taking this into account and auto-magically optimize the query?

Are there any other alternatives to implementing row-level security that can be enforced at the database level?

Appreciate the input

Cheers
Jonatan

В списке pgsql-general по дате отправления:

Предыдущее
От: "hendra kusuma"
Дата:
Сообщение: Serial - last value
Следующее
От: Marcus Engene
Дата:
Сообщение: where in (select array)