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

test: check net.ipv4.ip_unprivileged_port_start in parallel/test-cluster-bind-privileged-port #45838

Open
bnoordhuis opened this issue Dec 13, 2022 · 11 comments · May be fixed by #45904
Open

test: check net.ipv4.ip_unprivileged_port_start in parallel/test-cluster-bind-privileged-port #45838

bnoordhuis opened this issue Dec 13, 2022 · 11 comments · May be fixed by #45904
Labels
good first issue Issues that are suitable for first-time contributors. linux Issues and PRs related to the Linux platform. test Issues and PRs related to the tests.

Comments

@bnoordhuis
Copy link
Member

bnoordhuis commented Dec 13, 2022

test/parallel/test-cluster-bind-privileged-port.js expects binding to port 42 to fail but that's not an always-correct assumption.

Check the output of sysctl net.ipv4.ip_unprivileged_port_start because it's possible (albeit unlikely) for that port to be unprivileged.

Example output:

$ sysctl net.ipv4.ip_unprivileged_port_start
net.ipv4.ip_unprivileged_port_start = 1
@bnoordhuis bnoordhuis added test Issues and PRs related to the tests. good first issue Issues that are suitable for first-time contributors. linux Issues and PRs related to the Linux platform. labels Dec 13, 2022
@7suyash7
Copy link

7suyash7 commented Dec 15, 2022

$ sysctl net.ipv4.ip_unprivileged_port_start
net.ipv4.ip_unprivileged_port_start = 1024

Here's the output for me on Ubuntu 22.04.1

@bnoordhuis
Copy link
Member Author

bnoordhuis commented Dec 16, 2022

Yes, that's the default (and traditional UNIX behavior.) The test starts failing when it's <= 42.

@7suyash7
Copy link

7suyash7 commented Dec 16, 2022

So, you're saying the test should be modified to check the range of reserved ports on the current system, rather than assuming that it will always be 42?

@bnoordhuis
Copy link
Member Author

bnoordhuis commented Dec 16, 2022

The test should bail out with common.skip('...') if port 42 is unprivileged, yes.

@7suyash7
Copy link

7suyash7 commented Dec 16, 2022

Can I take a try at this? I would write a function to find the first unprivileged port and then try to attach a process to the port just before the first unprivileged port. Then basically the same checks as before (making sure the exit code is 0, etc) Is this implementation fine?
@bnoordhuis

@bnoordhuis
Copy link
Member Author

bnoordhuis commented Dec 16, 2022

Go for it but I'd rather it just exits if port 42 is unprivileged. Principle of least surprise and all that.

@7suyash7
Copy link

7suyash7 commented Dec 16, 2022

That makes sense, I'll send in a PR in some time!

7suyash7 added a commit to 7suyash7/node that referenced this issue Dec 16, 2022
7suyash7 added a commit to 7suyash7/node that referenced this issue Dec 16, 2022
@7suyash7
Copy link

7suyash7 commented Dec 16, 2022

@bnoordhuis PTAL.

@7suyash7
Copy link

7suyash7 commented Dec 16, 2022

Please ignore the second PR, I think it got added due to me changing branches locally and pushing.

@bnoordhuis
Copy link
Member Author

bnoordhuis commented Dec 18, 2022

Can you link me to your PR? I can't find it for some reason.

@7suyash7
Copy link

7suyash7 commented Dec 18, 2022

@bnoordhuis I messed up my Git locally and had to create a new PR. I hope you can see it now?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Issues that are suitable for first-time contributors. linux Issues and PRs related to the Linux platform. test Issues and PRs related to the tests.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants