Hacker News Reader

Comment by btilly | Hacker News Reader

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.

View on HN

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

Why is the developer doing this? Shouldn't someone skilled with infrastructure and an actual understanding of their environment do that work?

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.

It was already possible to configure this in a container with permissions.

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.

Oh all I'm saying is you can set the conf file to read-only. Basically this entire feature is "we want a nice error message".

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.

> will naturally prefer to try to fix things themselves

This is why shit infra that barely makes sense and barely works exists

Reply on news.ycombinator.com