Re: Bug #6593, extensions, and proposed new patch policy - Mailing list pgsql-hackers

Hi,

Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, Apr 18, 2012 at 7:54 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> However, ignoring that issue for the moment, this patch is making me
>> uncomfortable.  I have a vague recollection that we deliberately omitted
>> ALTER EXTENSION OWNER because of security or definitional worries.
>> (Dimitri, does that ring any bells?)  I wonder whether we should insist
>> that the new owner be a superuser, as the original owner must have been.

I remember not having included any OWNER in my submitted patch, because
I though we didn't really need one as far as the pg_extension entry is
concerned. You added one to better integrate with our standard practice
and for pg_dump purposes IIRC, but that's about it. I don't remember
that we talked about specific extension's objects owner: they get owned
by the user installing them.

> Don't we have non-superuser extensions, that can be installed with
> just DBA privileges?

We do, so the extension owner could well be the database owner and not a
superuser. That can only happens if the extension contains no C coded
parts, obviously, and that's why it's so easy to forget about --- plans
have been discussed to work on per-database module installation, not yet
about non-superuser installing a C module. I think the open possibility
of crashing the whole cluster is driving us not to relax the trusted bit
for the C language ever.

> Anyhow, it seems a bit nannyish, unless I'm missing something.  If the
> current owner is a superuser and s/he wants to give the object to a
> non-superuser, you can't really stop them.  They can just make the
> target user a superuser, give 'em the object, and make them not a
> superuser, all in one transaction no less.

The interesting use case would be reassigning the extension from a
database owner to a superuser so that the database owner can't remove it
nor upgrade it no more. I think we want to allow that.

The reassign from a superuser to a non-superuser can be argued both
ways, unless the extension is marked as superuser = true in the control
file. Which means we should better register that into the catalogs
because the control file can be updated on the file system and that's
out of reach for the cluster.

What about only issuing a WARNING that the extensions are not supported
by reassign owned in 9.1 (and probably 9.2)?

In next versions, we will be able to register the control file superuser
parameter and allow reassigning in a more controlled fashion, both the
catalog entry in pg_extension and the extension's objects.

Maybe rather than adding the control file into the catalogs piece after
piece we should install a copy of it at create/alter time in a database
specific location from the per major version shared location in the OS.
That way the user could be updating the OS shipped file then decide
which cluster and which database to upgrade with that, and you could
have PostGIS 1.5 in database foo and 2.0 in database bar. The OS would
still need to provide for a way to upgrade them separately, but that
would be much better than what we have now.

When doing things this way, we could trust the extension's control file
in cases such as ALTER EXTENSION OWNER, because it's now a private copy
of it.

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support