3 ms·

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

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.

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.