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
