Bug 1475137 - Permission denied for secrets mounting as files
Permission denied for secrets mounting as files
Status: CLOSED DUPLICATE of bug 1481617
Product: OpenShift Container Platform
Classification: Red Hat
Component: Pod (Show other bugs)
Unspecified Unspecified
unspecified Severity medium
: ---
: 3.6.z
Assigned To: Andrew McDermott
DeShuai Ma
Depends On:
  Show dependency treegraph
Reported: 2017-07-26 03:17 EDT by Takayoshi Tanaka
Modified: 2017-09-08 14:38 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2017-09-08 14:38:25 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Takayoshi Tanaka 2017-07-26 03:17:51 EDT
Description of problem:
When a user mounts secrets as files, mounted file can't be accessed by "permission denied" error.

Version-Release number of selected component (if applicable):

openshift v3.5.5.31
kubernetes v1.5.2+43a9be4

How reproducible:
In the customer side, always.
In my Lab, never. (the version is same)

Steps to Reproduce:
The customer created a public reproduction repository.

$ git clone https://github.com/brainsnorkel/test-os-subpaths
$ cd test-os-subpaths
$ oc new-project
$ ./oc-create-all.sh
$ ./testest-mounts+envs.sh  

Actual results:
the quick
brown fox
jumps over
the lazy dog
cat: can't open '/opt/test-secret.txt': Permission denied

Expected results:
the quick
brown fox
jumps over
the lazy dog

Additional info:
File permission info:
$ oc rsh $(oc get pods | grep Running | awk '// {print $1}') ls -als /opt
ls: /opt/test-secret.txt: Permission denied
total 4
     0 drwxr-xr-x    2 root     root            50 Jul 26 01:14 .
     0 drwxr-xr-x   19 root     root           217 Jul 26 01:14 ..
     4 -rw-r--r--    1 root     10001600        44 Jul 26 01:14 test-text.txt

The secret environment variable from the same secret is available:

$ oc rsh $(oc get pods | grep Running | awk '// {print $1}') sh -c set | grep -i SEKRIT_ENV

However, I can get the expected result at the same version of OCP Also, the customer can get the expected result at OSO v3.6.0-rc.0+98b3d56 and v1.5.0-rc.0
Comment 2 Ryan Howe 2017-08-04 19:41:08 EDT
        - mountPath: /opt/test-secret.txt
          name: volume-sekrit
          subPath: somexml
    - name: volume-sekrit
        defaultMode: 420
        secretName: sekrits

The root of this  issue is that the right selinux context is not set for the target.

drwxrwsrwt. root 1000080000 system_u:object_r:svirt_sandbox_file_t:s0:c4,c9 default-token-r5bmh
drwxrwsrwt. root 1000080000 system_u:object_r:tmpfs_t:s0     volume-sekrit

lrwxrwxrwx. root root system_u:object_r:svirt_sandbox_file_t:s0:c4,c9 /var/lib/origin/openshift.local.volumes/pods/5972781e-7967-11e7-96bd-fa163eb9684a/volumes/kubernetes.io~secret/volume-sekrit/somexml -> ..data/somexml
-rw-r--r--. root 1000080000 system_u:object_r:tmpfs_t:s0     /var/lib/origin/openshift.local.volumes/pods/5972781e-7967-11e7-96bd-fa163eb9684a/volumes/kubernetes.io~secret/volume-sekrit/..data/somexml

If I mount the secret 2x one with out the subpath it works as a workaround. 

Thinking its an error some where here in this code: 

Comment 3 Takayoshi Kimura 2017-08-08 04:05:20 EDT
It looks like a bug. With the subpath specified, only the subpath symlink gets relabeled. The symlink target, actual content file won't be relabeled and access denied.
Comment 4 Seth Jennings 2017-08-25 11:46:36 EDT
reducing to medium since customer issue is closed and there are workarounds.

Andrew, please take a look.  Probably just want to recreate first, then run it down.  Issue is with selinux labeling for secrets with using subPath.
Comment 7 Jan Pazdziora 2017-09-08 05:02:51 EDT
There is upstream issue https://github.com/openshift/origin/issues/15750 referencing this bugzilla which talks about upgrades. I wonder if the fact that the issue can be seen on one instance and not on another one of the same version (do I read it right?) is due to the fact that one instance was upgraded from older version and the other one was not.
Comment 8 Seth Jennings 2017-09-08 14:38:25 EDT
Looks like a dup of 1481617

*** This bug has been marked as a duplicate of bug 1481617 ***

Note You need to log in before you can comment on or make changes to this bug.