Re: RFC: seccomp-bpf support

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Joe Conway <mail(at)joeconway(dot)com>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Joshua Brindle <joshua(dot)brindle(at)crunchydata(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: RFC: seccomp-bpf support
Date: 2019-08-29 14:00:54
Message-ID: 18995.1567087254@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Joe Conway <mail(at)joeconway(dot)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. It doesn't help to say "I'm going to install
a lock to keep out a thief who *by assumption* is carrying lock
picking tools."

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Joshua Brindle 2019-08-29 14:17:29 Re: RFC: seccomp-bpf support
Previous Message fn ln 2019-08-29 13:55:47 Re: BUG #15977: Inconsistent behavior in chained transactions