Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> I don't understand Tom's resistance to this request.
It's false security. If you think you are going to prevent a superuser
from messing with the system's configuration, you are going to need a
lot more restrictions than this, and we'll be forever getting security
reports that "hey, I found another way for a superuser to get filesystem
access". I think the correct answer to this class of problems is "don't
give superuser privileges to clients running inside the container".
Ok, this is clearer. That makes sense now, and this probably helps me explain better the goal here. I also omitted in the initial email all the security precautions that a Kubernetes should take. This could be another step towards that direction but, you are right, it won't fix it entirely (in case of malicious superusers).
In my opinion, the biggest benefit of this possibility is on the usability side, providing a clear and configurable way to disable ALTER SYSTEM in those environments where declarative configuration is a requirement. For example, this should at least "warn" human beings that have the permissions to connect to a Postgres database (think of SREs managing a DBaaS solution or a DBA) and try to change a setting in an instance. Moreover, for those who are managing through declarative configuration not only one instance, but a Postgres cluster that controls standby instances too, the benefit of impeding these modifications could be even higher (think of the hot standby sensitive parameters like max_connections that require coordination depending whether you increase or decrease them).
I hope this is clearer. For what it's worth, I have done a basic PoC patch (roughly 20 lines of code), which I have attached here just to provide some basis for further analysis and comments. The general idea is to disable ALTER SYSTEM at startup, like this:
Thanks for your attention and looking forward to getting feedback and advice.