Re: RFC: seccomp-bpf support

On Tue, Jan 7, 2020 at 7:59 AM Tomas Vondra
<tomas(dot)vondra(at)2ndquadrant(dot)com> wrote:
> Barring objections, I'll mark it as rejected.

I think that's right. Since I just caught up on this thread, I'd like
to offer a few belated comments:

1. I don't think it would kill us to add a few hooks that would allow
this feature to be added by a loadable module. Someone may argue that
we should never add a hook unless we know exactly how it's going to be
used and agree with it as a goal, but I don't agree with that.
Refusing to add hooks just causes people to fork the server. If
somebody loads code that uses a hook at least you can tell that
they've done it by looking at shared_preload_libraries; if they fork
the server it may be much harder to tell that you're not dealing with
straight-up PostgreSQL. At any rate, ease-of-debugging considerations
for core developers should not take precedence over letting people do
with PostgreSQL what they wish.

2. I feel strongly that shipping this feature with mechanism but not
policy is unwise; I thought Alvaro articulated this problem
particularly well. I think the evidence on this thread is pretty
clear: this WILL break for some users, and it WILL need fixing. If the
mechanism is in core and the policy is not, then it seems likely that
employees at Crunchy, who apparently run into customers that need this
on a regular basis, will develop a set of best practices which will
allow them to advise customers as to what settings will or will not
work well, but because that knowledge will not be embedded in core, it
will be pretty hard for anybody else to support such customers, unless
they too have a lot of customers who want to run in this mode. I would
be a lot more supportive of this if both the mechanism and the policy
were going to ship in core and be maintained in core, with adequate
documentation.

3. The difficulty in making that happen is that the set of system
calls that need to be whitelisted seems likely to vary based on
platform, kernel version, glibc version, PostgreSQL build options,
loadable modules used, and which specific PostgreSQL features you care
about. I can't help feeling that this is designed mostly for processes
that do far simpler things than PostgreSQL. It would be interesting,
for example, to know what bash or perl does about this. They have the
same problem that PostgreSQL does, namely, that they are intended to
let users do almost arbitrary things by design -- not a totally
unlimited set of things, but an awful lot of things. Perhaps over time
this mechanism will undergo design changes, or a clearer set of best
practices will emerge, so that it's easier to see how PostgreSQL could
use this without breaking things. If indeed this is the future, you
can imagine something like glibc getting a "seccomp-clean" mode in
which it can be built, and if that happened and were widely used, then
the difficulties for PostgreSQL would be reduced. Because such
improvements typically happen over time through trial and error and
the efforts of many people, I think it is to our advantage to allow
people to experiment with the feature even as it exists today out of
core, which gets me back to point #1. I agree with Joshua Brindle's
point that holding our breath in response to a widely-adopted
technology is not a very useful response.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company