SELinux blocking despite no mounts and proper ownership

[Fodoj]

Follow up of #1666

Version:

1.18.2

Describe the bug

I got it with my custom image - quay.io/repository/fodoj/mattermost - you can try 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.

[brandond]

Do you have a link to the dockerfile? Looks like the only image there is quay.io/fodoj/mattermost:5.20.1 - is that correct?

[brandond]

How are you running this image to reproduce the error? It appears to be attempting to connect to a database. Can you provide a minimal k8s manifest that uses this image to reproduce the issue?

[brandond]

Also - it looks like there are a bunch of volumes defined for that image - are you sure that the permissions on files in those volumes are all correct? I don't think I've seen the specific error message you're getting.

[erikwilson]

Hopefully an upstream mattermost image can be used, sounds like it is a combination of the USER and VOLUME directive, like here: https://github.com/mattermost/mattermost-server/blob/master/build/Dockerfile#L31-L47

[davidnuzik]

@rancher-max

Test with RKE first (beta release has enhanced selinux support).
Then, later, we should test here in rancher/k3s from master or a v1.19 rc later.

[rancher-max]

Using RKE2, I am not able to reproduce the issue at all. Because of this, I believe that it is working correctly in RKE2, however I am hesitant to say it with 100% certainty since the reproduction steps aren't clearly defined for me. Using the information from this issue and the linked issue, however, it does not happen. Also, installing from mattermost's documentation also appears to be working correctly.

[davidnuzik]

@rancher-max spaced on K3s install from commitid functionality. Since you can install K3s using the install script from commitid, you can essentially test from master. Thus, you can move forward and test this in K3s too. Assigned the issue back to you.

[rancher-max]

Validated in K3S master commit id: 4a68698014bcc226169a112e18de32f6ec621d8d

• I used the example from the original issue, which is working correctly here.
• I also used the most updated image from this issue: quay.io/fodoj/mattermost:5.24.1 which seemed to work correctly
• Finally, I created my own image just for testing that does a simplified version of the issue mentioned with mattermost user. I exec'ed into this pod and ran ls -l to validate ownership:

ls -l
total 224
-rw-r--r--    1 mattermo mattermo      2052 Jul 31 12:30 ENTERPRISE-EDITION-LICENSE.txt
-rw-r--r--    1 mattermo mattermo    196761 Jul 31 12:30 NOTICE.txt
-rw-r--r--    1 mattermo mattermo      5554 Jul 31 12:30 README.md
drwxr-xr-x    2 mattermo mattermo        53 Aug 11 20:48 bin
drwxr-xr-x    7 mattermo mattermo      4096 Aug 11 20:48 client
drwxr-xr-x    2 mattermo mattermo        42 Aug 11 20:49 config
drwxr-xr-x    2 mattermo mattermo         6 Aug 11 20:48 data
drwxr-xr-x    2 mattermo mattermo        44 Aug 11 20:49 fonts
drwxr-xr-x    2 mattermo mattermo       255 Aug 11 20:49 i18n
drwxr-xr-x    2 mattermo mattermo         6 Jul 31 12:30 logs
drwxr-xr-x    2 mattermo mattermo         6 Aug 11 20:48 plugins
drwxr-xr-x    2 mattermo mattermo      4096 Aug 11 20:49 prepackaged_plugins
drwxr-xr-x    2 mattermo mattermo      4096 Aug 11 20:49 templates