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