Page MenuHomeFreeBSD

netinet: Disallow connections to INADDR_ANY
ClosedPublic

Authored by emaste on Nov 25 2024, 7:00 PM.
Tags
None
Referenced Files
Unknown Object (File)
Mon, May 26, 1:06 AM
Unknown Object (File)
Sat, May 24, 6:15 PM
Unknown Object (File)
Sat, May 17, 8:06 PM
Unknown Object (File)
Fri, May 9, 6:51 PM
Unknown Object (File)
Thu, May 8, 3:39 PM
Unknown Object (File)
Apr 28 2025, 11:42 PM
Unknown Object (File)
Apr 28 2025, 10:10 PM
Unknown Object (File)
Apr 21 2025, 3:07 AM

Details

Summary

Previously connect() or sendto() to INADDR_ANY reached some socket bound to some host interface address. Although this was intentional it was an artifact of a different era, and is not desirable now.

In 417b35a97b7669eb0bf417b43e97cccbedbce6f9 @markj added support to disallow connect() to INADDR_ANY. Take the next logical step and disable it by default.

[We can do a call for testing on -current first if desired. I'm certain that all potential fallout will not be found by such a request, though.]

Relnotes: Yes
PR: 280705

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

[We can do a call for testing on -current first if desired. I'm certain that all potential fallout will not be found by such a request, though.]

It might be worth giving a heads-up anyway, just so people have a hint if something stops working.

This revision is now accepted and ready to land.Nov 25 2024, 7:30 PM

It might be worth giving a heads-up anyway, just so people have a hint if something stops working.

Yeah, at least a post to -net and -current stating that the default changed, ask people to test if possible but at least be on the lookout for new misbehaviour, and advice on setting the sysctl to revert if necessary.

Does this need an entry in RELNOTES as a followup commit perhaps?

Does this need an entry in RELNOTES as a followup commit perhaps?

It will need a release note, indeed. We have at least two ways that can happen today -- as a result of Relnotes: Yes and by adding to RELNOTES. I believe RELNOTES was originally introduced to capture release notes where Relnotes: Yes was forgotten. It is probably better to capture the important aspect of the change at the time it happens and by the author of the change though, and perhaps we should deprecate Relnotes: Yes

Does this need an entry in RELNOTES as a followup commit perhaps?

It will need a release note, indeed. We have at least two ways that can happen today -- as a result of Relnotes: Yes and by adding to RELNOTES. I believe RELNOTES was originally introduced to capture release notes where Relnotes: Yes was forgotten. It is probably better to capture the important aspect of the change at the time it happens and by the author of the change though, and perhaps we should deprecate Relnotes: Yes

I think of Relnotes: yes as being a quick way to signal that someone _else_ should write a release note, whereas adding an entry to RELNOTES means that the release engineering team can just use that language without rewriting it. For trivial things like a version bump that is obvious from the commit log, I think Relnotes: yes is ok, but for anything non-trivial I think RELNOTES is better and we should encourage it.

Ed, is there any particular reason you didn't go ahead with this?

This revision was automatically updated to reflect the committed changes.

Ed, is there any particular reason you didn't go ahead with this?

It just slipped my mind, thanks for the reminder. I probably put it aside temporarily while pondering a RELNOTES entry and didn't get back to it.