Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
DescriptionBabak Mozaffari
2017-08-15 08:05:49 UTC
Created attachment 1313499[details]
Template to reproduce mount file issue
Description of problem:
The combination of mountPath and subPath should allow injecting a single file without overwriting the entire parent directory. This worked in OCP 3.5 but is broken in 3.6
Version-Release number of selected component (if applicable):
How reproducible:
Solution described no longer works in OCP 3.6: https://access.redhat.com/solutions/3100761
Steps to Reproduce:
1. Run the attached template: oc new-app -f mount-file.yml
2. Once the pod is on, hit the httpd homepage and see if the index.html file has been successfully replaced:
oc describe pod `oc get pods | grep Running | grep -v deploy | awk {'print $1'}`| grep IP | awk '{print $2}' | xargs -I @ curl -i @:8080
3. Once the pod is running, this curl command will return a value
Actual results:
HTTP/1.1 403 Forbidden
Expected results:
Success!
Master Log:
Node Log (of failed PODs):
PV Dump:
PVC Dump:
StorageClass Dump (if StorageClass used by PV/PVC):
Additional info:
If you rsh into the pod, for the two versions of OCP respectively:
*** OCP 3.6:
ls -l /opt/rh/httpd24/root/usr/share/httpd/noindex/
ls: cannot access /opt/rh/httpd24/root/usr/share/httpd/noindex/index.html: Permission denied
total 0
-????????? ? ? ? ? ? index.html
*** OCP 3.5:
ls -l /opt/rh/httpd24/root/usr/share/httpd/noindex/
total 4
-rw-r--r--. 1 root 1000620000 9 Aug 15 06:27 index.html
It has something to do with SELinux and the configMap index.html being a symlink (to ..data/index.html) under the hood. Docker will relabel index.html to svirt_sandbox_file_t, but the label of index.html doesn't actually matter, it's ..data/index.html which must be relabeled. The template will work if altered slightly to have `subPath: ..data/index.html`, but of course since this exploits an implementation detail of openshift this is not recommended as anything more than a temporary workaround...
I'm tempted to blame Docker for not following symlinks when relabelling volume files, but more investigation is needed to determine why this issue arose in 3.6.
IMO it is a bug that Docker does not follow symlinks when changing SELinux contexts via :Z.
The reason we're only seeing this now in 3.6 is https://github.com/openshift/origin/pull/12942. Prior to 3.6 we were insulated from the bug because every file under openshift.local.volumes was getting created with svirt_sandbox_file_t anyway, so even though index.html was chcon'd and ..data/index.html wasn't, the data could still be read from the container. (It's perhaps a separate security issue that the actual file ..data/index.html wasn't getting chcon'd because that means it wasn't getting the SELinux categories applied to it.)
We should fix the bug in Docker.
This appears to be blocking me as well.
When I deploy ocp 3.6 on azure, I need to update the registry config file,
and uses similar concept. This is now broken, resulting in registry not using the proper storage provider.
What AVC are you getting?
I take it this is the equivalent of doing
mkdir /var/foo
touch /var/foo/dan
ln -s /var/foo /var/bar
docker run -ti -v /var/bar:/var/bar:Z IMAGE sh
And you want SELinux to relabel /var/foo
sh-4.4# mkdir /var/foo
sh-4.4# touch /var/foo/dan
sh-4.4# ln -s /var/foo /var/bar
sh-4.4# docker run -ti -v /var/bar:/var/bar:Z fedora sh
/usr/bin/docker-current: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?.
See '/usr/bin/docker-current run --help'.
sh-4.4# systemctl start docker
sh-4.4# docker run -ti -v /var/bar:/var/bar:Z fedora sh
sh-4.3# ls -lZ /var/bar/
ls: cannot open directory '/var/bar/': Permission denied
Antonio does docker translate the volume mount of a symbolic link into its realpath before mounting? If so we should be passing this to SELinux not the symbolic link. If the kernel is doing this under the covers then we have a different issue.