On 8/29/19 10:00 AM, Tom Lane wrote: > Joe Conway <m...@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
signature.asc
Description: OpenPGP digital signature
