Re: RFC: seccomp-bpf support
| От | Joe Conway |
|---|---|
| Тема | Re: RFC: seccomp-bpf support |
| Дата | |
| Msg-id | c57900d8-f2c7-8998-927c-5e0e954444a9@joeconway.com обсуждение исходный текст |
| Ответ на | Re: RFC: seccomp-bpf support (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: RFC: seccomp-bpf support
|
| Список | pgsql-hackers |
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
Вложения
В списке pgsql-hackers по дате отправления: