6 ms·

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 com

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.

kbenson 3y ago
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.
- eddd-ddde 3y ago
  It's a super user. If you want safety, not using the super user would be a good start.
  - Denvercoder9 3y ago
    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.
    - camgunz 3y ago
      This was already possible with permissions.
- KingOfCoders 3y ago
  "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".
  - Too 3y ago
    Why is this a bad thing? 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.
  - kbenson 3y ago
    > 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.
whizzter 3y ago
It's an feature behind a commandline option?
madeofpalk 3y ago
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.
btilly 3y ago
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.
- akira2501 3y ago
  Why is the developer doing this? Shouldn't someone skilled with infrastructure and an actual understanding of their environment do that work?
  - btilly 3y ago
    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.
    - camgunz 3y ago
      It was already possible to configure this in a container with permissions.
      - btilly 3y ago
        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) 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.
hyperpape 3y ago
> 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.""
Denvercoder9 3y ago
> 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.
brand 3y ago
Your comment doesn’t seem to be in good faith. What cloud company is pushing this through?
- camgunz 3y ago
  If you click through the links in TFA, the three people pushing this feature all work for Enterprise DB (EDB?)
  - JelteF 3y ago
    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".
    - camgunz 3y ago
      Fair points!
  - brand 3y ago
    Okay, but EDB is the largest corporate contributor to Postgres, and one of the people pushing against the feature (Bruce Momjian) also works for EDB? The PG community is a lot of things, but I think “dominated by commercial interests” is not one of them. Disclosure: I work at EDB :)
- nijave 3y ago
  Depending on your definition of "cloud", all major PG contributors offer some sort of commercial or hosted solution. Citrus is part of Microsoft/Azure and EnterpriseDB offers hosting orchestrated on VMs and another option on Kubernetes. I think most of the people in the discussion were some variety of those companies.
alerighi 3y ago
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.
- MBCook 3y ago
  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.
- nijave 3y ago
  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.
cortesoft 3y ago
> push through a feature that bears risk of misconfiguration for everyone. What is the risk of misconfiguration? Someone might accidentally disable alter system? Seems like that isn't exactly a risk

kbenson 3y ago

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.

eddd-ddde 3y ago
It's a super user. If you want safety, not using the super user would be a good start.
- Denvercoder9 3y ago
  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.
  - camgunz 3y ago
    This was already possible with permissions.
KingOfCoders 3y ago
"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".
- Too 3y ago
  Why is this a bad thing? 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.
- kbenson 3y ago
  > 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.

whizzter 3y ago

It's an feature behind a commandline option?

madeofpalk 3y ago

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.

btilly 3y ago

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.

akira2501 3y ago
Why is the developer doing this? Shouldn't someone skilled with infrastructure and an actual understanding of their environment do that work?
- btilly 3y ago
  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.
  - camgunz 3y ago
    It was already possible to configure this in a container with permissions.
    - btilly 3y ago
      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) 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.

hyperpape 3y ago

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

Denvercoder9 3y ago

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

brand 3y ago

Your comment doesn’t seem to be in good faith. What cloud company is pushing this through?

camgunz 3y ago
If you click through the links in TFA, the three people pushing this feature all work for Enterprise DB (EDB?)
- JelteF 3y ago
  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".
  - camgunz 3y ago
    Fair points!
- brand 3y ago
  Okay, but EDB is the largest corporate contributor to Postgres, and one of the people pushing against the feature (Bruce Momjian) also works for EDB? The PG community is a lot of things, but I think “dominated by commercial interests” is not one of them. Disclosure: I work at EDB :)
nijave 3y ago
Depending on your definition of "cloud", all major PG contributors offer some sort of commercial or hosted solution. Citrus is part of Microsoft/Azure and EnterpriseDB offers hosting orchestrated on VMs and another option on Kubernetes. I think most of the people in the discussion were some variety of those companies.

alerighi 3y ago

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.

MBCook 3y ago
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.
nijave 3y ago
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.

cortesoft 3y ago

> push through a feature that bears risk of misconfiguration for everyone. What is the risk of misconfiguration? Someone might accidentally disable alter system? Seems like that isn't exactly a risk