Hi,
On 2018-04-27 16:34:04 -0400, Tom Lane wrote:
> So I thought for awhile about how to deal with that, and eventually
> decided that really what we need to do is solve this as part of the
> extension mechanism, not CREATE LANGUAGE per se. What I'm imagining
> is that we add new option(s) to extension control files that allow
> specifying that the extension's script is run as a different user
> than the user invoking CREATE EXTENSION. The extension object itself
> remains owned by the calling user (who can drop it), but the contained
> objects are then owned by the other user, so that the extension owner
> doesn't have privilege to modify or drop them individually.
> The ultimate security assumption behind this is that the contents of the
> extension script directory are superuser-approved, and so we can trust
> the contents of any script extension file to be OK to run as superuser
> if its control file says so. That'd be replacing the existing assumption
> that the contents of pg_pltemplate are superuser-approved. Perhaps
> there's a hole in that, but I don't see what; if an attacker can scribble
> on the extension script directory, it seems like it's already game over
> for database security.
> Anyway, this is all pretty sketchy, but I'd be willing to work towards
> making it happen in v12. Thoughts?
I don't think the extension control file is really the best place for
such policy decisions. An extension script can be safe, but not a great
idea for some installations nevertheless. I don't think it'd be a good
idea to require site operators to modify extension control files to tune
trustedness. I think it might be reasonable to have control file state
whether they *may* be set as trustable, but then the decision which
extensions a specific cluster determines as safe needs to be made in a
catalog or configuration file.
Greetings,
Andres Freund