-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
Allow privileged ports on WSL #19370
Allow privileged ports on WSL #19370
Conversation
Welcome @daniel-iwaniec! |
Hi @daniel-iwaniec. Thanks for your PR. I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
Can one of the admins verify this patch? |
/sig cli |
/kind cleanup |
/assign medyagh |
I tried to go through the documentation regarding the PR process and did what I could - let me know if there is anything more I can do :) |
I went through some of the WSL's GitHub issues and:
|
/sig network |
p, err := strconv.Atoi(port) | ||
if err != nil { | ||
return errors.Errorf("Sorry, one of the ports provided with --ports flag is not valid: %s", port) | ||
} | ||
if p > 65535 || p < 1 { | ||
return errors.Errorf("Sorry, one of the ports provided with --ports flag is outside range: %s", port) | ||
} | ||
if isHost && detect.IsMicrosoftWSL() && p < 1024 { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why isHost been removed from the logic ? doesnt seem related to this PR
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The way I understand it, the current logic is "on WSL (and only on WSL), check if the host port (and only host port) is below 1024", and since the change is to allow these ports on WSL, we don't need any special checks for host ports.
All that is left is port validation that applies to "every kind" of port - no matter if it is a host port or not.
@daniel-iwaniec thank you for this contribution do you mind sharing the Before/After this PR, with an example of using the WSL on windows? |
/ok-to-test |
This comment has been minimized.
This comment has been minimized.
Here are the number of top 10 failed tests in each environments with lowest flake rate.
Besides the following environments also have failed tests:
To see the flake rates of all tests by environment, click here. |
Current behavior on WSL
|
Expected behaviorWell, I obtained the output after building version with my changes, hence
|
@medyagh I replied to your comment and gave a before/after example Anyway, thanks for the quick response :) |
thank you @daniel-iwaniec for the before/after do you mind doing an example of this on a on WSL ? I know this PR wont break that I but I am suspecious that the code intended to be a" logical OR" and my be we meant to not allow ports bellow 1024 anywhere...it work on linux ? please also take a look at the unit test and make sure the unit tests are passing |
e0cd207
to
2101c4a
Compare
2101c4a
to
dd51e72
Compare
@medyagh these examples are done on WSL already Take a look at |
kvm2 driver with docker runtime
Times for minikube (PR 19370) start: 54.1s 52.8s 55.3s 53.3s 54.3s Times for minikube ingress: 24.5s 24.2s 28.1s 28.1s 24.2s docker driver with docker runtime
Times for minikube start: 24.5s 22.5s 25.3s 24.9s 23.6s Times for minikube ingress: 21.8s 21.3s 22.8s 21.8s 21.8s docker driver with containerd runtime
Times for minikube start: 24.6s 24.2s 20.8s 24.8s 24.1s Times for minikube ingress: 48.8s 47.9s 48.9s 38.0s 37.8s |
Here are the number of top 10 failed tests in each environments with lowest flake rate.
Besides the following environments also have failed tests:
To see the flake rates of all tests by environment, click here. |
Unit tests should also be fixed now, although I'm not sure how to trigger them |
yes I noticed that but I am wondering if this feature works on linux ? I have a feeling this "if isHost" statement been there for a reason and maybe it was meant to not allow it on Linux either |
I'm using Minikube like that on Linux all the time for years, without any issues. I only stumbled upon this issue when I started working with developers using WSL, which prompted me to create this PR. So yeah, it works fine on Linux 😄 Also, I already used binary with these changes on a few machines, and it is working fine |
{ | ||
isTarget: isMicrosoftWSL, | ||
ports: []string{"1023-1025:8023-8025"}, | ||
errorMsg: "Sorry, you cannot use privileged ports on the host (below 1024): 1023", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thank you @daniel-iwaniec for fixing the test, the Pr looks good just one last thing, can you plz emulate a secnario that the OS does NOT allow or can not create port bellow 1024 and see if minikube failed gracefuly ?
my fear is that for some new users this will blow with a large stack trace error if their OS does not allow this, it is good that we make sure minikube fails with a Nice one liner error that their OS didnt support it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would have to really go out of my way to make it not work :)
- This option (--ports) applies only to docker and podman
- docker and podman use
CAP_NET_BIND_SERVICE
by default - which means binding ports below 1024 should work by default
- docker and podman use
- In specific case of WSL, I confirmed it works both with
- docker engine
- docker desktop
- which means you could even install docker desktop on windows, then install minikube using WSL, and it still would work
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: daniel-iwaniec, medyagh The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Using ports below 1024 should be allowed on WSL in the same way as on Linux.
It should be left for the OS to decide whether it is allowed, respecting Linux Capabilities (e.g. CAP_NET_BIND_SERVICE), etc.
Going through the git history I got the impression, that it was left out for WSL to err on the safe side, but I don't see any explicit reason it should stay. Correct me if I'm wrong, please.
It doesn't fix any known issue as far as I know, I just noticed it myself and decided to create a new PR