On Wed, 2021-11-17 at 16:17 -0800, Mark Dilger wrote:
> You must choose a single role you want the subscription to run
> under.
I think that was the source of a lot of my confusion:
Your patches are creating the notion of a "run as" user by assigning
ownership-that-isn't-really-ownership. I got distracted wondering why
you would really care if some user could enable/disable/refresh/rename
a subscription, but the main point was to change who the subscription
runs as.
That's a more general idea: I could see how "run as" could apply to
subscriptions as well as functions (right now it can only run as the
owner or the invoker, not an arbitrary role). And I better understand
your analogy to security definer now.
But it's also not exactly a simple idea, and I think the current
patches oversimplify it and conflate it with ownership.
> I think the longer term plan is that non-superusers who have some
> privileged role will be allowed to create subscriptions,
You earlier listed some challenges with that:
https://postgr.es/m/CF56AC0D-7495-4E8D-A48F-FF38BD8074EB@enterprisedb.com
But it seems like it's really the right direction to go. Probably the
biggest concern is connection strings that read server files, but
dblink solved that by requiring password auth.
What are the reasonable steps to get there? Do you think anything is
doable for v15?
> There is a cart-before-the-horse problem here.
I don't think we need to hold up v2-0003. It seems like a step in the
right direction, though I haven't looked closely yet.
Regards,
Jeff Davis