On 8/29/19 10:00 AM, Tom Lane wrote:
> Joe Conway <mail@joeconway.com> writes:
>> Clearly Joshua and I disagree, but understand that the consensus is not
>> on our side. It is our assessment that PostgreSQL will be subject to
>> seccomp willingly or not (e.g., via docker, systemd, etc.) and the
>> community might be better served to get out in front and have first
>> class support.
>
> Sure, but ...
>
>> But I don't want to waste any more of anyone's time on this topic,
>> except to ask if two strategically placed hooks are asking too much?
>
> ... hooks are still implying a design with the filter control inside
> Postgres. Which, as I said before, seems like a fundamentally incorrect
> architecture. I'm not objecting to having such control, but I think
> it has to be outside the postmaster, or it's just not a credible
> security improvement.
I disagree. Once a filter is loaded there is no way to unload it short
of a postmaster restart. That is an easily detected event that can be
alerted upon, and that is definitely a security improvement.
Perhaps that is a reason to also set the session level GUC to
PGC_POSTMASTER, but that is an easy change if deemed necessary.
Joe
--
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development