Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

redis service: Listen on localhost by default #100195

Merged
merged 1 commit into from Nov 8, 2020

Conversation

@nh2
Copy link
Contributor

@nh2 nh2 commented Oct 11, 2020

Motivation for this change

Fixes #100192.

All other database servers in NixOS also use this safe-by-default setting.

Things done
  • Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
  • Built on platform(s)
    • NixOS
    • macOS
    • other Linux distributions
  • Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Determined the impact on package closure size (by running nix path-info -S before and after)
  • Ensured that relevant documentation is up to date
  • Fits CONTRIBUTING.md.
@nh2 nh2 self-assigned this Oct 11, 2020
@nh2 nh2 force-pushed the redis-listen-loopback-default branch from 837e843 to aa30039 Oct 11, 2020
Copy link
Member

@mweinelt mweinelt left a comment

I agree with this change in general, I'm not sure about the expectations of the release notes text. Should it mention a way to revert to the previous behaviour? Is this something we want to get into 20.09 if possible? Redis does by default listen on localhost on all other distros, so this honestly is unexpected behaviour. CC @jonringer

@nh2
Copy link
Contributor Author

@nh2 nh2 commented Oct 11, 2020

Should it mention a way to revert to the previous behaviour?

I don't think that is necessary, because the release notes describe what the previous and new behaviour are, and the the option docs explain how to to get the previous behaviour.

Is this something we want to get into 20.09 if possible?

My feeling is "no" because we're very close to the 20.09 release so it wouldn't get the usual testing of people wo run unstable in case there is fallout (even though I find it ulikely), and I it's not security critical because Redis makes it a no-op listener (thus I also think that the 1.severity: security label is not necessary).

It would make 20.09 slightly prettier, but I wouldn't land prettification changes last minute.

@mweinelt
Copy link
Member

@mweinelt mweinelt commented Oct 11, 2020

Protected mode

Unfortunately many users fail to protect Redis instances from being accessed from external networks. Many instances are simply left exposed on the internet with public IPs. For this reasons since version 3.2.0, when Redis is executed with the default configuration (binding all the interfaces) and without any password in order to access it, it enters a special mode called protected mode. In this mode Redis only replies to queries from the loopback interfaces, and reply to other clients connecting from other addresses with an error, explaining what is happening and how to configure Redis properly.

We expect protected mode to seriously decrease the security issues caused by unprotected Redis instances executed without proper administration, however the system administrator can still ignore the error given by Redis and just disable protected mode or manually bind all the interfaces.

Ah, this was probably added when that big fallout happened 3y back.

All other database servers in NixOS also use this safe-by-default setting.
@nh2 nh2 force-pushed the redis-listen-loopback-default branch from aa30039 to 169ab0b Nov 8, 2020
@nh2
Copy link
Contributor Author

@nh2 nh2 commented Nov 8, 2020

No counter arguments and this looks like a very good idea. Merging.

@nh2 nh2 merged commit 01a3fcc into NixOS:master Nov 8, 2020
2 of 4 checks passed
@mweinelt
Copy link
Member

@mweinelt mweinelt commented Nov 8, 2020

Yes, sorry for not getting back to you. This is indeed a good idea.

@nh2
Copy link
Contributor Author

@nh2 nh2 commented Nov 8, 2020

@mweinelt No problem, I didn't expect you to comment further -- my understanding was that you were already in support of the idea.

I just wanted to accompany my merge with a reason (that nobody came up and said it'd be bad).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

2 participants