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?
> (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.
> 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.