Re: RFC: seccomp-bpf support - Mailing list pgsql-hackers

On Tue, Jan 7, 2020 at 12:56 PM Tomas Vondra
<tomas.vondra@2ndquadrant.com> wrote:
> I think the "hook issue" is that the actual code is somewhere else. On
> the one hand that minimizes the dev/testing/maintenance burden for us,
> on the other hand it means we're not really testing the hooks. Meh.

I don't care about the testing the hooks. If we provide hooks and
someone finds them useful, great. If not, they don't have to use them.
The mere existence of this hook isn't going to put any significant
maintenance burden on the community, while the feature as a whole
probably would.

> Well, but this exact argument applies to various other approaches:
>
> 1) no hooks, forking PostgreSQL
> 2) hooks added, but neither code nor policy included
> 3) hooks aded, code included, policy not included
>
> Essentially the only case where Crunchy would not have this "lock-in"
> advantage is when everything is included into PostgreSQL, at which point
> we can probably make this work without hooks I suppose.

Well, from my point of view, in case 1 or 2, the feature is entirely
Crunchy's. If it works great, good for them. If it sucks, it's their
problem. In case 3, the feature is ostensibly a community feature but
probably nobody other than Crunchy can actually make it work. That
latter situation seems a lot more problematic to me. I don't like
PostgreSQL features that I can't make work. If it's too complicated
for other developers to figure out, it's probably going to be a real
pain for users, too.

Putting my cards on the table, I think it's likely that the proposed
design contains a significant amount of suckitude. Serious usability
and security concerns have been raised, and I find those concerns
legitimate. On the other hand, it may still be useful to some people.
More importantly, if they can more easily experiment with it, they'll
have a chance to find out whether it sucks and, if so, make it better.
Perhaps something that we can accept into core will ultimately result.
That would be good for everybody.

Also, generally, I don't think we should block features (hooks or
otherwise) because some other company might get more benefit than our
own employer. That seems antithetical to the concept of open source.
Blocking them because they're poorly designed or will impose a burden
on the community is a different thing.

> I think this is probably the main challenge of this patch - development,
> maintenance and testing of the policies. I think it's pretty clear the
> community can't really support this on all possible environments, or
> with third-party extensions. I don't know if it's even possible to write
> a "universal policy" covering significant range of systems? It seems
> much more realistic that individual providers will develop policies for
> systems of customers.

I generally agree with this, although I'm not sure that I understand
what you're advocating that we do. Accepting the feature as-is seems
like a no-go given the remarks already made, and while I don't think I
feel as strongly about it as some of the people who have already
spoken on the topic, I do share their doubts to some degree and am not
in a position to override them even if I disagreed completely. But,
hooks would give individual providers those same options, without
really burdening anyone else.

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