Re: Extension Templates S03E11 - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: Extension Templates S03E11
Date
Msg-id 1385950950.19125.53.camel@jdavis
Whole thread Raw
In response to Re: Extension Templates S03E11  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
Responses Re: Extension Templates S03E11
List pgsql-hackers
On Sun, 2013-12-01 at 15:58 +0100, Dimitri Fontaine wrote:
> Jeff Davis <pgsql@j-davis.com> writes:
> Either of those solution are fine to me, with or without the automated
> SET ROLE when a superuser is installing an extension from a template
> owned by a non-superuser.
> 
> Tell me your preference, I'll work on the code.

This version (for this 'fest) should be superuser-only, because we don't
have enough consensus about the security model.

That being said, we don't want to prevent a change to allow
non-superusers in the future. So let's collect a few ideas, and leave
room to implement one of them later.

To throw another idea out, also based on the premise that it's a
namespace problem: if a non-superuser creates an extension template,
then we force a prefix of that user's username. So a superuser can
create an "base" extension template with no prefix, but if I create an
extension template it would be called something like "jdavis"."foo". To
be more consistent, we could have a reserved prefix that's always
assumed, similar to pg_catalog.

> I still think about extensions as being a per-database thing, and that
> the current security policy makes if a per-major-version thing when the
> extension contains a module (.so).
> 
> Also, the dynamic_library_path already allows us to make binary
> extensions a per-database object again, baring incompatibilities that
> would manifest themselves as run-time errors…
> 
> So I strongly vote against making the Extension Templates a set of
> shared catalogs.

I don't have much of an opinion on this point, but I also don't
understand your point. Can you clarify? What's the use case for
DB-specific extension templates?

I generally think of extension templates as universal, in that
"myExtension version 1.2.3" is exactly the same everywhere, and
immutable, so why not share it?

I understand why extensions (not templates) are per-DB, because you
might want to control which objects are available, and also control
which namespace they go in.

Regards,Jeff Davis





pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Draft release notes for 9.3.2
Next
From: Stephen Frost
Date:
Subject: Re: Extension Templates S03E11