Not very happy that a group of people with vested interests (cloud companies) push through a feature that bears risk of misconfiguration for everyone. Mongo comes to mind with all the problems they had around a false feeling of security.
I think if the the config is unchangeable, all ways to change the config (e.g. don't reload config on demon restart etc.) should be considered. Or the config piped into PG on startup, not reading any files. But this takes time to do right.
This had to be in on short notice (trys to move this to another release where squashed) b/c vested interests.
Just because it's kubernetes doesn't mean it's cloud companies. This is a useful feature for anyone that wants repeatable deployments of pistresql. That can be cloud, or it can be k8s, or it can be an automated testing pipeline.
I think the top comment on the LWN article gets it right. Don't think of it as a SECURITY feature, think of it as a SAFETY feature. Imagine some subset of buttons on a physical control panel than can be locked behind a flimsy plastic door. It's not going to keep anyone determined out, but it will keep people from using them on accident.
"Just because it's kubernetes doesn't mean it's cloud companies. "
All of the people driving this work for companies that sell postgres hosting. This is why they are driving this, to make their own offering cheaper to operate, customers can't use "ALTER SYSTEM" and destroy the managed DB creating problems.
Their intent is not for Kubernetes users, this might be a side effect, but for their own companies. If your developers use ALTER SYSTEM and then deploy to production without changing prod conf, I'd say talk to the developers.
It's irrelevant on how it is meant to be, it's 100% relevant on how it is perceived.
The feature is driven by "We're power users and we know what to do and what this is" whereas the resistance is "Yes, but there are a million users, they are not power users, they will shoot themselves in the foot, and then PG will gain a bad rep for security".
Assume one guy in my team does ALTER SYSTEM on a cloud managed DB. Next month he leaves, later someone redeploys the DB, nothing works and nobody knows why. Declarative config and IaC has become standard operations to solve real world problems.
Besides that, if I wanted to operate the system internals of a DB myself I wouldn’t be using a cloud-hosted version in the first place. I pay them precisely to manage all these details so I don’t have to think about it. If I don’t want that there are a lot cheaper alternatives.
> All of the people driving this work for companies that sell postgres hosting.
Even if that's true (and I'm not sure it is, there seemed to be plenty of people in support of the feature), that doesn't mean it only benefits them. Plenty of features are championed by one group but benefit many others, so perhaps evaluating whether it's good based on who asked for it isn't a useful strategy.
> The feature is driven by "We're power users and we know what to do and what this is"
That's not how I perceived it. There are, as was noted in the article, multiple ways to do this, and even ways to enforce it currently. To me this seems very clearly a case of users, and people responsible for providing it to users, wanting a feature to make the quality of life of those users better (anyone that does an ALTER SYSTEM in the environments they are referring to is going off-track and going to cause themselves a problem) and attempting to work with upstream to provide a solution rather than using kludges (such as making the files immutable, but possibly not getting a useful error from postgresql when the command fails) or implementing local patches, so it's not necessarily exactly the same as the mainline postgresql.
> the resistance is "Yes, but there are a million users, they are not power users, they will shoot themselves in the foot, and then PG will gain a bad rep for security".
No, the resistance did not seem to be that the users will shoot themselves in the foot, from what I read. It was that they were afraid security researches would see this as a security mechanism, but since it's not necessarily hard to bypass they would get called out for poor security, affecting the reputation of the project. I'm not sure how you expect millions of users to shoot themselves in the foot by having to enable a flag that prevents them from doing this and then attempting to do it. It's not default behavior, it's specifically opt-in behavior. And if it's clearly not a security feature, but a safety feature to help people from doing things they shouldn't in environment that it will cause problems in, then hopefully security researchers won't waste their time with erroneous CVEs.
That's about as useful as saying "it's a chainsaw, if you want safety, don't use one". Sometimes powerful tools are necessary, but a bit of protection to avoid accidents when using them is not a bad thing.
This is meant to solve the problem of, "Developer tries to fix something in their local environment, gets it working, then finds it gets thrown away when they restart Kubernetes. Winds up convinced that PostgreSQL is broken."
That's a real use case. The right way to address it is an easy to place speed bump. It isn't some complex solution that achieves a random security ideal which has little to do with the use case. And would make configuration harder.
That's exactly why this is being described as a safety feature, not a security feature.
A similar thing happens in networking. A router gets updated. In a few months the router is rebooted and config is lost. Air circulators are covered in excreta because someone forgot to saveconfig.
Happens all the time in less disciplined workplaces.
"Developer tries to fix something in their local environment, gets it working, then finds it gets thrown away when they restart Kubernetes. Winds up convinced that PostgreSQL is broken."
No, it tries to fix the problem of Postgres managed hosting companies, where users can use ALTER SYSTEM but can't change *.conf - all of the people driving this, work for companies that offer managed hosting. The "Developer tries..." is just a fake argument, b/c "We, the Postgres hosting companies want this" would probably not work. So it's the "For the developer ..."
In 25 years I never used ALTER SYSTEM in Postgres for my local development, I always made changes to *.conf - if for the idiotic reason that whatever you Google, you get an answer to change some entry in *.conf not an answer to ALTER SYSTEM
Because when you're working with a containerized setup, it is standard for every developer to have the whole setup on their individual work computer.
A developer debugging problems on their own computer will naturally prefer to try to fix things themselves rather than depend on an external admin whose attention is hard to get. And you have every tool necessary to try to do so.
I can neither confirm nor deny that of my own knowledge.
I'll merely say that if it is possible, then I'd expect this detail to have been in the article. Because the existence of an acceptable solution for the use case would have been an important part of the discussion.
As evidence for my point of view, the article early on points out that Tom Lane thought that there was a way to do it. And even described how to do it. But it turned out that he was wrong.
Now I'd be shocked if either of us knew PostgreSQL nearly as well as https://en.wikipedia.org/wiki/Tom_Lane_(computer_scientist). The fact that he thought there was a way to do it makes it reasonable that you'd think the same. The fact that he couldn't come up with a way to do it without changing PostgreSQL suggests that, like he was initially, you're wrong.
But as I say, my evidence is circumstantial. And I'd be open to learning what it is in case I ever again wind up setting up PostgreSQL on an old version for a containerized system. Though in a new system I'd prefer to use the mechanism created specifically for this purpose.
That's how I see it too. Not security, but developer experience. You set the file as readonly, but provide a message to PostgreSQL superuser that this is as intended
This is discussed in LWN comments, in fact. But the problem there is that the protocol used to communicate the fact that the file is read-only to the application (errno==EACCESS or equivalent on other platforms) does not provide any useful way for the system administrator who makes the file read-only to add a notice explaining why permission is denied, in a way that it is also communicated to the app - so that it could display it to the user.
So the proper solution to this whole thing would be for the OS to provide such a facility: "permission X is denied to Y because Z". This seems like a useful facility in general, come to think of it. But it would have taken more time and effort, and would require buy-in from more parties, some of whom might be very hostile to this notion (e.g. I don't think it would be an easy thing on Linux). No wonder that this isn't an option that is even contemplated as realistic.
And so instead we got yet another easy-to-make crutch in the tower of crutches and duck tape that is modern software.
There seems to be major lack of communication in the threads as evidenced by Tom Lane's "I never objected to the idea of being able to disable ALTER SYSTEM"
I guess a technical understanding of Postgresql leads to different thoughts than your average working dev/devops/ops person.
Which, TBF characterizes a lot of tech discussions.
> will naturally prefer to try to fix things themselves
That's precisely my point. They aren't "fixing" anything. They're creating blind workarounds that simply let them continue developing.
> And you have every tool necessary to try to do so.
So containers are an entirely inappropriate mechanism to containerize things? Thus we have to patch software that runs in the container to be container aware to avoid problems /created/ by developers "fixing" things?
Very natural indeed. What benefit that brings just happens to be entirely beyond me.
Doesn't everyone working on Postgres have 'vested interests' on working on it?
Isn't this what we want - that people have their own various motivations for contributing to an open source project? A healthy process is one that allows for contributions, variously motivated, to be discussed and accepted or not.
I think the problem here is not only related to cloud environments. Is having an SQL command that writes the configuration file a good idea to start with? It's probably something dangerous, I prefer to SSH into the machine and edit the config file by hand, possibly adding comments describing why I've set a parameter to a specified value, rather than doing it with an SQL command.
I also think that is a feature that is rarely used, that probably shouldn't be on by default.
See I read that Postgres did that and thought “what a great idea!” I’ve seen so many stories of people who changed something important at runtime in their DB/router/managed switches/whatever and then forgot about it until after a restart “broke” things 2 years later and the change is lost forever.
Maybe contentious but I'd argue the ability to rewrite config files at runtime with SQL is the thing that makes more sense being an extension although it's existed for so long as a core feature, it's non trivial to change.
> This had to be in on short notice (trys to move this to another release where squashed) b/c vested interests.
From the article:
> Even then, the discussion was not quite done; Momjian questioned merging this change so late in the PostgreSQL development cycle. ""My point is that we are designing the user API in the last weeks of the commitfest, which usually ends badly for us"". Fennema-Nio pointed out that the API was essentially unchanged from its initial, September form, and that months had been spent discussing alternatives. Haas said that such a small patch would not improve by being held up for another release cycle: ""I think it has to be right to get this done while we're all thinking about it and the issue is fresh in everybody's mind.""
I wanted to clarify that I (Jelte, the author of the final patch) work at Microsoft. So, it's definitely not just one company seeing benefit in this feature. Arguably Microsoft is a cloud company too though, but honestly most of the active contributors to PostgreSQL work at a "cloud company".
> I think if the the config is unchangeable, all ways to change the config (e.g. don't reload config on demon restart etc.) should be considered.
What? The goal isn't to make the configuration unchangeable, it's to ensure that all configuration changes go through the configuration management system. You need to have a reload option that reloads the configuration from disk.
This is not something that's just useful for cloud companies btw, it's useful in any scenario where you're doing configuration/change management.
I think if the the config is unchangeable, all ways to change the config (e.g. don't reload config on demon restart etc.) should be considered. Or the config piped into PG on startup, not reading any files. But this takes time to do right.
This had to be in on short notice (trys to move this to another release where squashed) b/c vested interests.