feat: allow privileged_role to manage FDWs
#39
Conversation
soedirgo
force-pushed
the
bs/privileged-role-fdw
branch
from
43a242f to
007ebe4
Compare
soedirgo
force-pushed
the
bs/privileged-role-fdw
branch
from
007ebe4 to
8fbe5dd
Compare
soedirgo
force-pushed
the
bs/privileged-role-fdw
branch
from
8fbe5dd to
2aa24dd
Compare
src/supautils.c
Outdated
|
|
||
| run_process_utility_hook(prev_hook); | ||
|
|
||
| // GRANT USAGE on the FDW so we can do CREATE SERVER. |
There was a problem hiding this comment.
If we're already superuser, why do we need this GRANT USAGE?
There was a problem hiding this comment.
The privileged_role won't be a superuser, so after the FDW is created, it needs GRANT USAGE to do CREATE SERVER ... FOREIGN DATA WRAPPER ...
There was a problem hiding this comment.
One alternative I considered is to make the privileged_role the owner of the FDW, but since you need to be a superuser to own a FDW, I had to temporarily make the privileged_role a superuser - a bit icky, but might be a cleaner end state?
There was a problem hiding this comment.
but might be a cleaner end state?
If we can avoid mutating the privileged role here it'd be better. Otherwise users could revoke this usage and be left confused why the fdw fails.
There was a problem hiding this comment.
Looks good. I see we can drop the FDW despite not being superuser later on.
There was a problem hiding this comment.
Ah nice catch, simplified the code a bit
soedirgo
force-pushed
the
bs/privileged-role-fdw
branch
from
061f34b to
f1f220f
Compare
Incorporates supabase/supautils#39 which unblocks Wrappers
Incorporates supabase/supautils#39 which unblocks Wrappers
Incorporates supabase/supautils#39 which unblocks Wrappers
Incorporates supabase/supautils#39 which unblocks Wrappers
What kind of change does this PR introduce?
feature
What is the current behavior?
Non-superusers can't manage FDWs, which is a blocker for https://github.com/supabase/wrappers
What is the new behavior?
privileged_rolecan create/alter/drop FDWs.