* Andres Freund (andres@anarazel.de) wrote:
> On 2015-07-29 10:38:19 -0400, Tom Lane wrote:
> > Well, there's a larger issue, which is that (a) Andrew's new installation
> > very likely doesn't have dummy_seclabel.so built/installed at all
>
> Hm. That issue doesn't particularly concern me. Having all .so's
> available in the installation seems like a pretty basic
> requirement. Security labels are by far not the only things that'll fail
> without an extension's .so present, no?
It's certainly an issue that postgis users are familiar with.
> > (b) even if he did, there's nothing that would cause it to get loaded
> > during pg_upgrade's DDL restore run.
>
> Well, generally it's assumed that all security labels are loaded via
> shared_preload_libraries. I'm not super happy about that decision, but
> given the desire to be able to have labels on shared objects I can see
> the reasoning.
Yes.
> > 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.
>
> I think if we think we should do something here we should add a check
> that label providers are loaded in s_p_l.
That has caused issues with the buildfarm in the past.. I'd like to
have a way to do that though, for label providers and potentially other
things which should really only be loaded via s_p_l.
Thanks!
Stephen