Re: Proposal: Introduce row-level security templates
От | Stojan Dimitrovski |
---|---|
Тема | Re: Proposal: Introduce row-level security templates |
Дата | |
Msg-id | CALTcmgm7Cm32aXVxqBcjixTKRJqPC40oGFPBnz0txeddkkf7_Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Proposal: Introduce row-level security templates (Aadhav Vignesh <aadhav.n1@gmail.com>) |
Ответы |
Re: Proposal: Introduce row-level security templates
(Aadhav Vignesh <aadhav.n1@gmail.com>)
|
Список | pgsql-hackers |
Hi Aadhav Vignesh, Interestingly, Alexander asked for ideas for GSoC projects at Supabase (I'm on the Auth team), and I proposed the RLS templates idea. As you already pointed out, the idea comes out of us seeing how RLS policies are used in real-life and the pain points associated with managing a non-trivial number of them. I am not a code contributor to Postgres, so please excuse my lack of knowledge on how internals work or what's best to implement. From your original message: https://www.postgresql.org/message-id/CAMuaUMJ10_4CDxtHOTHbp%2BY%2Bh2uR2wxcVtJPbBvp9A9Njs5kUA%40mail.gmail.com In my opinion, as a user of the policies, I prefer the direction of option (2) with `CREATE POLICY TEMPLATE`. It’s much closer to the existing `CREATE POLICY` statements, a lot of the internals could probably be reused, which would make the project move along faster. I do think there should be the option to attach it immediately to tables, something like `CREATE POLICY TEMPLATE <name> ATTACH TO <tables> AS ...` but it’s not a deal-breaker for me. I don’t really know enough about how this actually works internally, but on this point: > The major challenge here is the construction of the qualifiers for the > policy, as the entire process [1] relies on a table ID, however, we don’t > have access to any table names in this statement. > > I also find the aspect of constructing qualifiers directly from the > plain-text state less ideal, and I honestly have no clue if this is > possible. I would say that because templates are not active until they’re attached, the logic for “validating” the query part should come when the template is being attached on the table. So a non-qualifying `USING` clause would error out on the `ATTACH` command. Similarly, altering the policy template would force validation on the clause over the already attached tables to the policy. I would also suggest looking into the ability to attach a template to a schema. There are some obvious benefits of this — creating a table in the schema automatically gets the correct RLS behavior without having to explicitly attach a template or policies, making it secure-by-default. There is some interesting behavior of this as well which _may_ be beneficial. For example, if you create a schema-wide template, say `user_id = current_user`, and you create a table that doesn’t have a `user_id` column — the creation would fail. This is in many practical situations beneficial, as it lessens the likelihood of creating a table that can’t be properly secured in that application context. On the flip side, it’s probably going to be challenging to implement this and there may be other implications too (like adding it in `ALTER TABLE`, etc). Some fringe ideas that I also think are worth exploring are: 1. Make the `ON table_name` part of the `CREATE POLICY` statement optional, which would create the “template.” This would require altering the internals of the policy-table relationship to support 0, 1, 2, … tables instead of the current 1. Again I have no idea how this is implemented internally, but it could be a fairly simple change without having to introduce new concepts, objects, and commands. 2. Have templates only as the object that enables the one-to-many relationship between a policy and table. For example, you could create a policy like `CREATE POLICY owned_by_user ON table ...`, and then you could do something like `CREATE POLICY TEMPLATE owned_by_user AS POLICY schema.table.owned_by_user ATTACH TO tables...`. So essentially the “template object” just references an already existing policy attached to a table, and it allows you to attach it to other tables too. Let me know what you think! (Apology if this email is not threaded in your email client, I'm writing it after subscribing to the list, which means the Reply option is not available.)
В списке pgsql-hackers по дате отправления:
Следующее
От: Andrew DunstanДата:
Сообщение: Re: Trying to build x86 version on windows using meson