Re: upgrade failure from 9.5 to head - Mailing list pgsql-hackers

Tom,

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Andres Freund <andres@anarazel.de> writes:
> > On 2015-07-29 10:38:19 -0400, Tom Lane wrote:
> >> Now as far as dummy_seclabel is concerned, the easy answer is "we don't
> >> care".  But on reflection, doesn't this mean that the entire
> >> implementation of SECURITY LABEL is broken?  At least to the extent that
> >> it can't work during pg_upgrade unless the user takes manual action to
> >> configure the relevant providers' .so libraries into the new installation
> >> *before* he runs pg_upgrade.  That doesn't say "production ready" to me.
>
> > Hm, I don't think that particular issue is that bad. We decided labels
> > are only going to work if they're in shared_preload_libararies, and they
> > really only do if that's the case.
>
> In that case, where in the documentation of the pg_upgrade process does
> it say "you must configure the new installation with all security label
> providers installed in shared_preload_libraries after initdb'ing the
> new installation and before running pg_upgrade"?  And how can you meet
> that requirement if you are using a canned script that does both those
> steps for you?  (Red Hat certainly ships such a script in their packaging,
> and I rather imagine that the Debian-style packages do too.)

The Debian packages have a place where you can drop scripts to be run
during the process to address exactly this issue.  I specifically asked
for that to be added because of the issues with doing PostGIS upgrades.

> And even more to the point, why exactly should security providers get this
> dispensation when we don't make people jump through hoops like that for
> anything else?  AFAICS, with the way things are now, if you simply load
> a dump script without bothering with setting up shared_preload_libraries,
> then you have all the objects loaded and no security labels attached to
> them.  Isn't that a security breach by definition?

Upgrades are not part of normal operation and if you goof it up then,
yes, you're going to run into problems, but anyone who is going through
that process is going to care quite a bit about making sure they do it
correctly, including testing the process before going through it on a
real system.

> I think it's fairly broken if pg_upgrade output, or pg_dump output in
> general, can't be loaded without such requirements.  Perhaps we could
> have the dump script issue a LOAD for the label providers that will be
> referenced; or maybe better, fix "SECURITY LABEL FOR provider" so that
> it autoloads the relevant provider, which would require either a mapping
> table or some convention about the .so name for a provider.
>
> IMO, the current situation is fine for toy providers like dummy_seclabel,
> but if you want the feature to ever be regarded as more than a toy,
> this issue needs work.

I'm all for improving on the current situation.  I agree that it's not a
terribly good state to be in.
Thanks!
    Stephen