[HN Gopher] The PostgreSQL community debates ALTER SYSTEM
___________________________________________________________________
The PostgreSQL community debates ALTER SYSTEM
Author : fforflo
Score : 102 points
Date : 2024-04-19 05:39 UTC (2 days ago)
(HTM) web link (lwn.net)
(TXT) w3m dump (lwn.net)
| KingOfCoders wrote:
| 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 wrote:
| 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 wrote:
| It's a super user. If you want safety, not using the super
| user would be a good start.
| Denvercoder9 wrote:
| 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 wrote:
| This was already possible with permissions.
| whizzter wrote:
| It's an feature behind a commandline option?
| madeofpalk wrote:
| 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 wrote:
| 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 wrote:
| Why is the developer doing this? Shouldn't someone skilled
| with infrastructure and an actual understanding of their
| environment do that work?
| btilly wrote:
| 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 wrote:
| It was already possible to configure this in a container
| with permissions.
| btilly wrote:
| 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_(comput
| er_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.
| akira2501 wrote:
| > 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.
| hyperpape wrote:
| > 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 wrote:
| > 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 wrote:
| Your comment doesn't seem to be in good faith. What cloud
| company is pushing this through?
| camgunz wrote:
| If you click through the links in TFA, the three people
| pushing this feature all work for Enterprise DB (EDB?)
| JelteF wrote:
| 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".
| alerighi wrote:
| 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.
| noodlesUK wrote:
| I don't understand the purpose of this. If what's being said is
| true, alter system being disabled wouldn't prevent the super user
| from doing all the same things as alter system but in a less
| convenient way. It will just give people a false sense of
| security, because they can abuse COPY to overwrite the config.
| whizzter wrote:
| Then it'd be very purposeful, the idea of this kind of patch
| would be that someone Googling random older PG answers to fix a
| random issue wouldn't be tempted to just issue an ALTER
| command, think the issue is fixed and then find out after a
| restart/rebuild that the fix is not there any more.
|
| This not a security patch but more of a safeguard against
| hapless idiots manhandling themselves without resistance in an
| unsupported case.
| kbenson wrote:
| As a comment on the LWN article noted, it might be better to
| think of it as a safety feature, not a security feature.
| btilly wrote:
| See my comment at https://news.ycombinator.com/item?id=40107325
| for the use case.
|
| It is a safety feature that can help avoid people getting
| confused when working in a containerized environment. It is not
| a security feature at all. Nor is it intended to be. It is
| meant so that people like me can set up a configuration that
| will work better for coworkers who know less about databases
| than I do.
| noodlesUK wrote:
| Then surely the answer should be that there should be a
| config setting that disables it, with the option to do
| something like "WITH FORCE" which would force enable it in
| the environment even with that config setting enabled. This
| gives the best of both worlds, in that it stops people from
| copying blindly from Stack Overflow, but doesn't give the
| sense of security that it initially seems to imply.
| btilly wrote:
| Yes, lots of people had ideas about this should work.
| Exactly like you just did. Unfortunately they had different
| ideas. And that's why there was months of debate over how
| this feature should work before something was accepted.
|
| Just to give one example of an obvious problem with your
| idea, saying "WITH FORCE" will suggest to some that this
| configuration setting is somehow forcibly maintained. This
| is likely to generate bug reports based on that
| misunderstanding. "I said WITH FORCE and it is easy to get
| around!" And, worse yet, questions about, "Why do we have a
| security feature that doesn't provide any security?"
| olliemath wrote:
| Speaking as somebody who has had to debug why servers were
| ignoring changes to the configs in our git repos, this is a
| welcome change.
|
| It's a shame there are ways to bypass it, but at least it
| communicates the intent: you aren't supposed to modify this
| system without modifying the actual config
| SOLAR_FIELDS wrote:
| While I agree that ALTER SYSTEM change is probably a good thing,
| I also see the pain and perspective of the people who were
| pushing back.
|
| Anyone who has had to work in security knows about the endless
| deluge of low effort script kiddie "security reports" of non
| issues they have to deal with by security "researchers" fishing
| for a bounty. And you have to read all of them, because there's
| no telling when one might be legitimate. Or you bring in some
| third party auditor for compliance or some other reason and they
| are just as clueless and snap up something like this to add to
| their list of "recommendations" that you have to respond to so
| they can feel like they are more justified collecting the
| paycheck.
|
| So I think implementing the feature - but being extremely loud
| about what it is and isn't - is the right move here.
| gizmo686 wrote:
| I work on building security hardended systems, and often see
| the opposite problem. Engineers, even ones who should really
| know better, will see a feature like this and assume it creates
| an actual security boundary. Then they design something that
| relies on it for a security requirement. At that point, you
| need to hope someone catches the mistake, but even then, you
| can spend a week arguing with a non-technical manager that you
| need to start over, because that thing that sounds like it does
| exactly what you want actually provides 0 security guarantees.
| noodlesUK wrote:
| I completely agree with this. If something seems at first
| blush to enforce a security control, but does not in reality,
| it should somehow be made _very_ clear that it is just
| disabling a footgun rather than actually enforcing a security
| control. Either the setting in the config file needs to be
| named something silly like
| disable_alter_system_not_a_security_feature, or it needs to
| be overridable with something like "WITH FORCE", to make it
| really clear that all it is is a stumbling block rather than
| a control.
| vbezhenar wrote:
| Can I make this file read only? Will that prevent alter system
| from working?
| btilly wrote:
| I'm very glad to see this option added. If I could add one thing
| to it, it would be to display a custom message when ALTER SYSTEM
| is disabled. You know, one that would let the person setting it
| up tell the person trying the command where in the repo the
| configuration file that should be edited can be found instead.
| candiddevmike wrote:
| I wish they had a more declarative way for provisioning (and de
| provisioning) users and databases. I'd like to define these at
| startup and have them reconciled automatically without having to
| do a deployment+psql dance to manage them.
| convolvatron wrote:
| that's kind of an odd thing to say. all of that state is really
| held in Postgres tables. all of the various tools just
| manipulate those. you could quite trivially write a tool that
| would take a big yaml or something and splat that.
| candiddevmike wrote:
| I'd rather PostgreSQL handle this so I don't have to create a
| privileged user and write a custom reconcilation loop.
| adam_gyroscope wrote:
| This would be a welcome change for folks running PG in k8s or
| with any external automated configuration management. Once you
| want to deploy Postgres databases via API to semi-trusted users
| you want to have configuration control outside of the database
| itself. We disabled this at bit.io via patches - would have been
| nice if upstream had this.
| gfodor wrote:
| I wonder why they didn't go with the file system permissions on
| the .auto.conf file, and gracefully handling that as a way to
| disable the feature. Seems like an obvious solution that doesn't
| lead to surprising semantics. The container use case would work
| fine.
| captn3m0 wrote:
| pg applying the change and failing to persist it (in case of a
| write failure) is the acceptable behaviour probably? Write
| failures leading to alter failures would count as a surprise.
|
| But after disabling alter system, you can use permissions to
| avoid local overrides, so this is probably worth adding in the
| docs.
| robocat wrote:
| That is discussed in the comments of the article.
| JelteF wrote:
| One of the authors of the patch here. Two reasons:
|
| 1. This config option approach was extremely easy to implement
|
| 2. Because making this auto.conf read-only would break many
| existing tools around Postgres that write to auto.conf
| camgunz wrote:
| Containerization was bad enough when it was just the result of
| not wanting to learn how to run services on Linux, but now we're
| actively modifying system software to make containerization
| "easier" (not really easier, just more in line with its ethos)?
| Let's hope this kind of thing doesn't become a trend.
| zxspectrum1982 wrote:
| This one feature doesn't really seem to be container-related
| but configuration as code-related.
___________________________________________________________________
(page generated 2024-04-21 23:00 UTC)