On Tue, Sep 12, 2023 at 10:39 AM Martín Marqués <martin.marq...@gmail.com> wrote: > The outcome looked for is that the system GUCs that require a restart > or reload are not modified unless it's through some orchestration or > someone with physical access to the configuration files (yeah, we > still have the COPY PROGRAM).
If I understand this correctly, you're saying it's not a security vulnerability if someone finds a way to use COPY PROGRAM or some other mechanism to bypass the ALTER SYSTEM restriction, because the point of the constraint isn't to make it impossible for the superuser to modify the configuration in a way that they shouldn't, but rather to make it inconvenient for them to do so. I have to admit that I'm a little afraid that people will mistake this for an actual security feature and file bug reports or CVEs about the superuser being able to circumvent these restrictions. If we add this, we had better make sure that the documentation is extremely clear about what we are guaranteeing, or more to the point about what we are not guaranteeing. I understand that there's some frustration on the part of Gabriele and others that this proposal hasn't been enthusiastically adopted, but I would ask for a little bit of forbearance because those are also, by and large, not the people who will not have to cope with it when we start getting security researchers threatening to publish our evilness in the Register. Such conversations are no fun at all. Explaining that we're not actually evil doesn't tend to work, because the security researchers are just as convinced that they are right as anyone arguing for this feature is. Statements like "we don't actually intend to guarantee X" tend to fall on deaf ears. In fact, I would go so far as to argue that many of our security problems (and non-problems) are widely misunderstood even within our own community, and that far from being something anyone should dismiss as pedantry, it's actually a critical issue for the project to solve and something we really need to address in order to be able to move forward. From that point of view, this feature seems bound to make an already-annoying problem worse. I don't necessarily expect the people who are in favor of this feature to accept that as a reason not to do this, but I do hope to be taken seriously when I say there's a real issue there. Something can be a serious problem even if it's not YOUR problem, and in this case, that apparently goes both ways. I also think that using the GUC system to manage itself is a little bit suspect. I wonder if it would be better to do this some other way, e.g. a sentinel file in the data directory. For example, suppose we refuse ALTER SYSTEM if $PGDATA/disable_alter_system exists, or something like that. It seems like it would be very easy for an external management solution (k8s or whatever) to drop that file in place if desired, and then it would be crystal clear that there's no way of bypassing the restriction from within the GUC system itself (though you could still bypass it via filesystem access). I agree with those who have said that this shouldn't disable postgresql.auto.conf, but only the ability of ALTER SYSTEM to modify it. Right now, third-party tools external to the server can count on being able to add things to postgresql.auto.conf with the reasonable expectations that they'll take effect. I'd rather not break that property. -- Robert Haas EDB: http://www.enterprisedb.com
