On Sun, 2013-12-01 at 15:58 +0100, Dimitri Fontaine wrote:
> Jeff Davis <pg...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
