-
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
CentOS 7 with SELinux prevents containers to run #1666
Comments
Thanks for reporting @Fodoj. I was able to verify this behavior is a problem by comparing it to running docker with selinux enabled. |
Issue is resolved. Verified using k3s v1.18.2-rc4+k3s1
|
I tried with 1.18.2. The postgres issue from the example above seems to be fixed, by I encounter another problem. I got it with my custom image - quay.io/repository/fodoj/mattermost - you can to re-produce it, it's a publicly available image (just a packaging around Mattermost). But I can also try to provide a more concrete test case, once I have more time to do so. The issue I have is this: There is a user, mattermost, part of the group - mattermost. There is a file inside the image which is owned by mattermost:mattermost and has rw permissions for owner. Despite this permissions and the user inside the container being mattermost, I get permission denied error, which can be only SELinux related from the first glance. |
Thanks for the info @Fodoj! If you are able to file a new issue using the mattermost image that would be greatly appreciated. Would also be nice to see a comparison of process & mount labels using k3s w/ docker & selinux enabled vs using k3s w/ embedded containerd. |
Version:
Installation script:
Describe the bug
Take this YAML:
Then
kubectl create -f pod.yaml
Note it happens with multiple other images as well, not just postgresql. But postgresql is easiest to use to re-produce
Expected behavior
postgresql starts fine
Actual behavior
In logs:
In audit logs (parsed with sealert for better output, I installed setroubleshoot-server for this to work):
Additional context / logs
Putting SELinux to Permissive mode resolves the issue.
The text was updated successfully, but these errors were encountered: