Permission denied when checking out source to /workspace

[chmouel]

Expected Behavior

When checking out a PipelineResource with a Git resource checking it out in /workspace which run as user (as for example by default on OpenShift) the Git repository would probably be checked out in /workspace/src.

Actual Behavior

This would be denied and can't create directory in /workspace

mkdir: can't create directory '/workspace/source': Permission denied

Steps to Reproduce the Problem

This is maybe an OpenShift specific issue or a K8s with a hardened policy to force running the pods as random user instead of privileged.

Running this on OpenShift4.2 with a simple Task with a PipelineResource of Git will do, i.e:

---
apiVersion: tekton.dev/v1alpha1
kind: Task
metadata:
  name: waitforever-with-src
spec:
  inputs:
    resources:
      - name: source
        type: git
        targetPath: src
  steps:
    - name: waitforever
      image: registry.access.redhat.com/ubi8/ubi-minimal:latest
      workingdir: /workspace/src
      command: ["sleep", "infinity"]
---
apiVersion: tekton.dev/v1alpha1
kind: PipelineResource
metadata:
  name: source
spec:
  type: git
  params:
    - name: url
      value: https://github.com/rogertinsley/golang-k8s-helloworld

and run it with :

apiVersion: tekton.dev/v1alpha1
kind: TaskRun
metadata:
  generateName: waitforever-with-src-run-
spec:
  inputs:
    resources:
    - name: source
      resourceRef:
        name: source
  taskRef:
    kind: Task
    name: waitforever-with-src

Additional Info

Weirdly enough this only appeared lately like for the last two weeks or so but can't find anything obvious in the git logs (perhaps that's an OpenShift 4.2 specific bug too).

Debugging a bit into this, this would fail into the initContainers that initialize the /workspace directories.

The first container which does the credsInit run fine and adding some debugs I can see that I have the sticky bit set to be able to write into /workspace :

While the second initContainer which does the dir-init step would fail, adding a ls -l just before doing the mkdir -p I can see that the the sticky bit has dropped in there and mkdir would fail because we are running as user and directory is set as root :

/kind bug

[chmouel]

Doh! /workspace volume is not getting mounted, the yaml part of the failed step, dir-init :

while it is mounted and then working in the previous initContainer step credentials-init :

I guess the reason is when we did the refactoring we have missed the volumeMounting in there :

https://github.com/tektoncd/pipeline/blob/master/pkg/pod/workingdir_init.go#L77-L82

/cc @imjasonh

/assign