[postgis-devel] About EXTENSION from UNPACKAGED on PostgreSQL 13

[Stephen Frost]

Greetings,

* Sandro Santilli (strk at kbt.io) wrote:
> On Thu, Feb 27, 2020 at 12:33:52PM -0500, Stephen Frost wrote:
> 
> > > Can you give an example attack vector ?
> > 
> > It's really not hard to imagine..  If an existing object is owned by a
> > non-superuser and you put it into a package, and then use that object in
> > some way during the extension script (which is running as a superuser..)
> > then someone could gain superuser access.
> 
> Ok, this is something we can fix. Worth a ticket, in the road to
> become a trusted extension. But we can fix (we can check ownership of
> objects before packaging them).
> 
> > There are also issues if you
> > end up with functions in untrusted languages that are owned by
> > non-superusers.
> 
> Same fix: we can check ownership before packaging.

What are you going to do if the ownership is wrong?  How do you know
what the "right" ownership is?

> > Considering the PG folks have, quite resonably, decided that it's not
> > trivial to "plug those holes" and aren't planning to provide any support
> > for doing so, I seriously, seriously, doubt that you would be able to
> > somehow as an extension.
> 
> Dubts are of no help. An exact case scenario showing an impossible
> to fix hole would. Can you provide that ? I do have some thoughts
> about search paths and friends but not a definitive attack vector
> (we CREATE OR REPLACE functions anyway).

I don't doubt that there's *lots* of ways to break it.  I do not have to
show every possible way to show that it's an objectively bad idea that's
going to break, and I'm not particularly interested in spending the time
to knock down every idea you come up with for how to "solve" it.

> > I strongly feel that this is a seriously bad idea.  Unpackaged installs
> > really shouldn't exist these days and trying to hack around things to
> > make it safe to turn some random jumble of functions into an extension
> > is just a really bad idea.
> 
> I guess we can avoid the randomness.

Yes- by knowing that the existing objects came from a prior extension
script that created them, which is the entire point.

> > Properly install the extension and then migrate to it.
> 
> This would mean forcing a dump/reload, right ?

Of course, but why are we stressing about this?  CREATE EXTENSION has
been around for a long, long time.

If people wanted to migrate to a packaged extension, they certainly have
had plenty of opportunity to do so.  If they don't want to migrate,
then, if you want, continue to provide upgrade scripts that upgrade
their jumble of functions, and make them have to be a superuser to run
them and deal with the potential fallout.

The actual use-case for "take this jumble of functions and turn them
into an extension" is vanishingly small today.

Thanks,

Stephen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20200227/fb2b5908/attachment.sig>