On Tue, Jan 7, 2020 at 4:36 PM Stephen Frost <sfrost@snowman.net> wrote:
> Here's the thing though.. creating the extension isn't *really* (in our
> permissions model anyway) what lets you create outbound connections-
> it's creating a 'SERVER', and to be able to do that you need to have
> USAGE rights on the FDW, which, normally, only a superuser can create.
> The crux here is that the FDW is created as part of the extension
> though. As long as only superusers can create extensions, that's fine,
> but when we allow others to do so, we come to an interesting question:
>
> No matter how we end up allowing a non-superuser to create a trusted
> extension, who should end up owning it and being able to modify it
> and/or grant access to objects within it?
Hmm. Good question. But it's addressed in the documentation for the
patch Tom wrote, so I don't know why we need to discuss it de novo.
His answer seems pretty sensible and also happens to, I think, match
what you've written here.
> Of course, there's the other option, which is to just agree that,
> because of the way postgres_fdw works, it's gotta be marked as
> untrusted. I would ask though- are we really sure that we aren't ever
> going to have any issues with functions in untrusted languages (or any
> other objects) created by extensions being owned by non-superusers?
But I don't see what the question of "who owns the objects?" has to do
with whether a superuser might want to allow some extensions to be
installed but not others. I think someone might want that, and if I
understand correctly, Tom thought so too when he wrote v1 of the
patch, because it had some capabilities along these lines. All I'm
doing is arguing that his first instinct was correct. And I'm not even
sure that you're disagreeing, since you seem to think that the
question of whether postgres_fdw ought to be marked trusted is
debatable. I'm really not sure what we're arguing about here.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
