Jeff Davis <pg...@j-davis.com> writes: >> When a superuser CREATE EXTENSION against a template that has been >> provided by a non-privileged user, automatically SET ROLE to that user >> before doing so, avoiding escalation privileges. > > That proposal is worded like a special case for superusers, and I don't > see why. If the security model is that an extension script is run with > as the template owner, then we should just do that universally. If not, > making a special case for superusers undermines the security of > powerful-but-not-superuser roles.
I like that idea yes. > I haven't looked in detail at the security issues here... is this the > result of a consensus or are there still differing opinions? AFAIK past reviewers came up with the privilege escalation use case and said we'd better have that feature a superuser only one. It's playing safe, but I wish we could find another solution. > We already have a model for executing functions, and those are black > boxes of code as well. If we deviate too much from that, I think we're > inviting problems. So maybe we should have “SECURITY DEFINER” and “SECURITY INVOKER” extension templates, the default being “SECURITY DEFINER”? > Aside: why do file-based templates shadow catalog-based templates? > Shouldn't we just throw an error if both are available at CREATE > EXTENSION time? That sounds good too. We need to ERROR out at UPDATE time too of course. > Also, I notice that the extension templates are not in shared catalogs; > was that discussed? Yes it was. The current model for extensions is to be per-database, but it's limited by the way we deal with modules (.so), for security reasons that encompass the per-database model. Also consider multi-tenancy installations. Certainly, you don't want any database owner to be able to review PL code from any other database owner in the same cluster when each database owner is another customer. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
