-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
rancher/k3s:v1.31.3-k3s1
messing with network device permissions
#11429
Comments
rancher/k3s:1.31.3-k3s1
messing with network device permissionsrancher/k3s:v1.31.3-k3s1
messing with network device permissions
Can you reproduce this on standalone k3s or is this only a k3d problem? I have no idea what you're doing with this here. |
Cross linking issues here. Not sure where the source of the issue is: kubernetes/kubernetes#129157 I am using the stable tag and the version bumped last night. |
Possibly a containerd or runc change? What specific versions of k3s did you upgrade from/to? Are you using selinux? |
I am using the stable channel, so I assume this: c827805 1.30.6 -> 1.31.3 And yes, selinux. |
Following this thread: opencontainers/runc#3468 (comment) For docker, seems like adding:
The equivalent in Kubernetes though still seems to required privileged permissions:
|
Traced back to runc, an intended break. Unfortunately means granting privileged now for creating tun devices, and during the transition containers will fail to start: tailscale/tailscale#14262 (comment) |
Closing, as this was an intentional change in runc: |
Thanks @maggie44 , great find! |
Is it possible to revert this change in a point release (1.31.2 -> 1.31.3)? Going to a major API breaking change at a point release seems like a bad idea. There is also talk of reverting the change. See my other comment about the long term security implications of this: |
No. As I said on the other issue you commented on, we can update runc again if they decide to change behavior in a new release, but we are not planning to revert the version bump here. |
They have reverted the commit which casuing the issue. #4556 |
We'll keep an eye out for v1.2.4. |
Environmental Info:
K3s Version:
1.31.3-k3s1
Node(s) CPU architecture, OS, and Version:
Linux k3d-home-media-server-server-0 5.15.167.4-microsoft-standard-WSL2 #1 SMP Tue Nov 5 00:21:55 UTC 2024 x86_64 GNU/Linux
Cluster Configuration:
Describe the bug:
Upgrading the rancher image from
rancher/k3s:v1.31.2-k3s1
torancher/k3s:v1.31.3-k3s1
causes permissions errors when accessing/dev/net/tun
inside thegluetun
container.Please find the file structure and contents as follows.
File structure:
File contents:
Steps To Reproduce:
mullvad
username as the value of theOPENVPN_USER
environment variable intemplates/gluetun.yaml
k3d cluster create --config k3d-config.working.yaml
helm upgrade --install k3s-1.31.3-test .
glueton-0
pod toRunning
kubectl logs gluetun-0
and note successfully runningk3d cluster create --config k3d-config.broken.yaml
helm upgrade --install k3s-1.31.3-test .
glueton-0
pod toError
kubectl logs gluetun-0
and note permission denied error for/dev/net/tun
Expected behavior:
The
/dev/net/tun
file should be accessible as it was inv1.31.2-k3s1
.Actual behavior:
Getting the a permission denied error inside the gluetun container when attempting to open the
/dev/net/tun
device.Additional context / logs:
Error from inside gluetun container when using
v1.31.3-k3s1
The text was updated successfully, but these errors were encountered: