-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How to set security_invoker automatically? #95
Comments
hey @ianschmitz, I know this issue is old, but it has been on my mind for a while because it was really surprising to me that this was the default behavior and there was no way to specify the security invoker. As a workaround, I would typically patch the generated view like this:
Of course, that was far from ideal. Today, I found this PR, and I was wondering whether setting SECURITY INVOKER at the time of applying the security label would generate a And according to my tests, it does indeed. Note: I tested it using DBeaver's DDL generation over the view, as other tools such as Supabase Admin Studio never show the security invoker part in a view DDL, regardless of whether it has it or not. |
@fabricior interesting. Are you thinking this is more of a documentation issue? For context i'm coming from pgsodium usage within Supabase. |
@ianschmitz yes, same here. I read about all this in a supabase blog post IIRC. I was thinking of creating an issue/pr if it is not fixed already |
@ianschmitz By the way, it is no longer a documentation issue for this repo. I've just seen that about 20 days after you created this issue, the Readme file was updated to include information about how to set the security invoker:
|
Currently every time we use:
SECURITY LABEL FOR pgsodium ON COLUMN ...
it generates/replaces a decrypted view. This view does not have
security_invoker = on
by default.We can use a separate command to enable it:
However if we were to enable encryption on another column from the same table, this would remove
security_invoker
since the view is replaced.I'm not really sure what the right solution is here, but i did find it a bit surprising and clearly since
security_invoker
is such a critical configuration property of a view to enable RLS, having it removed is a big security issue.Should
security_invoker
be enabled by default on supported Postgres versions? Should it remain on the newly generated view if it existed on the previous version? Should we be able to specify it when callingSECURITY LABEL
?Thanks for your consideration!
The text was updated successfully, but these errors were encountered: