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

On Tue, Jan 07, 2020 at 11:33:07AM -0500, Robert Haas wrote:
>On Tue, Jan 7, 2020 at 7:59 AM Tomas Vondra
><tomas.vondra@2ndquadrant.com> wrote:
>> Barring objections, I'll mark it as rejected.
>
>I think that's right.

Done.

>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.
>

Not sure I understand. I don't think anyone argued by hooks vs. forking
the server in this particular thread, but the thread is fairly long so
maybe I'm missing something.

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.

But in this case I think the main argument against hooks was that Tom
thinks it's not really the right way to implement this. I don't know if
he's right or not, I don't have an opinion on how to integrate seccomp.

>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.
>

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.

>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.
>

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.


regards

-- 
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services