Steps can't use creds-init credentials when their UID is different from creds-init UID and disable-home-env-overwrite=true

[ghost]

Expected Behavior

When a Step has its own non-root UID which is different from creds-init any credentials should still be usable by that Step.

Actual Behavior

The Step will fail to utilize credentials.

When disable-home-env-overwrite is "true" the Step's entrypointer tries to copy credentials out of /tekton/creds into $HOME. But the UID of the Step is different from creds-init. The files inside of /tekton/creds are owned by whatever user creds-init ran as. The Step is disallowed from reading those files as it tries to copy them out.

Steps to Reproduce the Problem

Set disable-home-env-overwrite feature flag to "true". Redeploy tekton. Apply taskrun:

apiVersion: tekton.dev/v1beta1
kind: TaskRun
metadata:
  name: test
spec:
  taskSpec:
    steps:
    - name: check-dirs
      image: ubuntu
      env:
      - name: HOME
        value: /myhome
      securityContext:
        runAsUser: 1111
        runAsGroup: 2222
      script: |
        id
        echo $HOME
        ls -lahR /tekton/creds

See errors in step logs. Example: unsuccessful cred copy: ".ssh" from "/tekton/creds" to "/workspace": unable to open source: open /tekton/creds/.ssh/known_hosts: permission denied

Additional Info

Originally discussed here: https://github.com/tektoncd/pipeline/issues/2165

[ghost]

Here's a slightly more in-depth illustration of the problem:

[check-dirs] 2020/05/08 16:33:24 unsuccessful cred copy: ".docker" from "/tekton/creds" to "/myhome": unable to create destination directory: mkdir /myhome: permission denied
[check-dirs] 2020/05/08 16:33:24 unsuccessful cred copy: ".gitconfig" from "/tekton/creds" to "/myhome": unable to open source: open /tekton/creds/.gitconfig: permission denied
[check-dirs] 2020/05/08 16:33:24 unsuccessful cred copy: ".git-credentials" from "/tekton/creds" to "/myhome": unable to open source: open /tekton/creds/.git-credentials: permission denied
[check-dirs] 2020/05/08 16:33:24 unsuccessful cred copy: ".ssh" from "/tekton/creds" to "/myhome": unable to create destination directory: mkdir /myhome: permission denied
[check-dirs] + id
[check-dirs] uid=1111 gid=2222 groups=2222
[check-dirs] /myhome
[check-dirs] + echo /myhome
[check-dirs] + ls -lahR /tekton/creds
[check-dirs] /tekton/creds:
[check-dirs] total 8.0K
[check-dirs] drwxrwxrwt 4 root root  120 May  8 16:33 .
[check-dirs] drwxr-xr-x 8 root root 4.0K May  8 16:33 ..
[check-dirs] drwxr-xr-x 2 root root   60 May  8 16:33 .docker
[check-dirs] -rw------- 1 root root    0 May  8 16:33 .git-credentials
[check-dirs] -rw------- 1 root root   29 May  8 16:33 .gitconfig
[check-dirs] drwxr-xr-x 2 root root  100 May  8 16:33 .ssh
[check-dirs]
[check-dirs] /tekton/creds/.docker:
[check-dirs] total 4.0K
[check-dirs] drwxr-xr-x 2 root root  60 May  8 16:33 .
[check-dirs] drwxrwxrwt 4 root root 120 May  8 16:33 ..
[check-dirs] -rw------- 1 root root  12 May  8 16:33 config.json
[check-dirs]
[check-dirs] /tekton/creds/.ssh:
[check-dirs] total 12K
[check-dirs] drwxr-xr-x 2 root root 100 May  8 16:33 .
[check-dirs] drwxrwxrwt 4 root root 120 May  8 16:33 ..
[check-dirs] -rw------- 1 root root 110 May  8 16:33 config
[check-dirs] -rw------- 1 root root  23 May  8 16:33 id_fake-ssh-directory
[check-dirs] -rw------- 1 root root  28 May  8 16:33 known_hosts

creds-init has written credentials to the /tekton/creds directory as the root user. So the files it wrote are owned by root/root. My Step runs as user 1111 in group 2222. So my Step is not able to open those creds for reading.

[ghost]

One way this could play, discussed during API Working Group, is that we deprecate the creds-init behaviour entirely and remove it when switching to v1beta2. It's a holdover from the very earliest days of Tekton / Knative Build so it simply might not make sense to retain the behaviour much longer.