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