Andres Freund <and...@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.)
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?
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.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
