git-clone permissions issues when workspace uses volumeClaimTemplate

[adam-power]

Expected Behavior

When I create a Pipeline and PipelineRun object referencing the git-clone resolver, I expect to be able to configure the PipelineRun to use a volumeClaimTemplate to back the "git-source" workspace, so I can pass the cloned Git repository to later tasks.

Actual Behavior

During execution of the git-clone task, I get a permissions error because the task is running as the git user and the PVC mounted to /workspace/output/ is owned by root.

This is the full error:

Defaulted container "step-clone" out of: step-clone, prepare (init), place-scripts (init)
+ '[' false '=' true ]
+ '[' false '=' true ]
+ '[' false '=' true ]
+ CHECKOUT_DIR=/workspace/output/
+ '[' true '=' true ]
+ cleandir
+ '[' -d /workspace/output/ ]
+ rm -rf /workspace/output//lost+found
+ rm -rf '/workspace/output//.[!.]*'
+ rm -rf '/workspace/output//..?*'
+ test -z
+ test -z
+ test -z
+ git config --global --add safe.directory /workspace/output
+ /ko-app/git-init '-url=https://github.com/tektoncd/catalog.git' '-revision=main' '-refspec=' '-path=/workspace/output/' '-sslVerify=true' '-submodules=true' '-depth=1' '-sparseCheckoutDirectories='
{"level":"error","ts":1679929403.1163123,"caller":"git/git.go:53","msg":"Error running git [init /workspace/output/]: exit status 1\n/workspace/output/.git: Permission denied\n","stacktrace":"github.com/tektoncd/pipeline/pkg/git.run\n\tgithub.com/tektoncd/pipeline/pkg/git/git.go:53\ngithub.com/tektoncd/pipeline/pkg/git.Fetch\n\tgithub.com/tektoncd/pipeline/pkg/git/git.go:88\nmain.main\n\tgithub.com/tektoncd/pipeline/cmd/git-init/main.go:53\nruntime.main\n\truntime/proc.go:250"}
{"level":"fatal","ts":1679929403.116427,"caller":"git-init/main.go:54","msg":"Error fetching git repository: exit status 1","stacktrace":"main.main\n\tgithub.com/tektoncd/pipeline/cmd/git-init/main.go:54\nruntime.main\n\truntime/proc.go:250"}

Steps to Reproduce the Problem

1. Create this Pipeline:

---
apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
  name: app-deploy-test
spec:
  params:
  - name: git-url
  - name: git-revision
  - name: file-path
  workspaces:
  - name: git-source
  tasks:
  - name: fetch-from-git
    taskRef:
      resolver: git
      params:
      - name: url
        value: https://github.com/tektoncd/catalog.git
      - name: pathInRepo
        value: /task/git-clone/0.9/git-clone.yaml # not-working
        # value: /task/git-clone/0.7/git-clone.yaml # working
      - name: revision
        value: main
    params:
    - name: url
      value: $(params.git-url)
    - name: revision
      value: $(params.git-revision)
    workspaces:
    - name: output
      workspace: git-source
  - name: show-files
    runAfter: [fetch-from-git]
    taskRef:
      name: show-files
    workspaces:
    - name: git-repo
      workspace: git-source
    params:
    - name: file-path
      value: "$(params.file-path)"

---
apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
  name: show-files
spec:
  params:
  - name: file-path
    description: Path to the files to show
  workspaces:
  - name: git-repo
  steps:
  - name: show-files
    workingDir: $(workspaces.git-repo.path)
    image: busybox:latest
    script: |
      #!/bin/sh

      set -x

      pwd
      ls -l $(params.file-path)

2. Create this PipelineRun:

---
apiVersion: tekton.dev/v1beta1
kind: PipelineRun
metadata:
  name: app-deploy-test
spec:
  pipelineRef:
    name: app-deploy-test
  params:
  - name: git-url
    value: https://github.com/tektoncd/catalog.git
  - name: git-revision
    value: main
  - name: file-path
    value: "./"
  workspaces:
  - name: git-source
    volumeClaimTemplate:
      spec:
        accessModes:
        - ReadWriteOnce
        resources:
          requests:
            storage: 1Gi

Additional Info

If you switch the above pipeline from 0.9 to 0.7, it successfully lists the files. I believe this is because 0.7 and earlier versions ran as root, whereas 0.9 runs as the non-root git user.

[shahzebrizvi16]

I have been facing the same exact issue as stated above. I even modified my pipelineRun to include spec.podTemplate.securityContext.fsGroup:65532 . But I still got the same issue.

I looked further in to it and seems like despite setting the fsgroup to non root, the mounted workspace is still owned by the root user when in fact the owner should be 65532. This is important especially since the git-clone task run as a non-root user.
Shouldn't setting the fsgroup change the user of the mounted workspace?

[prageshmaurya]

This issue mostly depends upon the type of volume mount. I have recently faced this issue while mounting PVC created through Azure file storage CSI where Azure file share doesn't allow you to change permission after its creation. You can specify your volume claim to help more on this.

[tekton-robot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale with a justification.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/lifecycle stale

Send feedback to tektoncd/plumbing.

[tekton-robot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten with a justification.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/lifecycle rotten

Send feedback to tektoncd/plumbing.