-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
.ssh/* files do not have expected/required permissions when copied into custom home dir #3509
Comments
Hm, interesting. In the code we create directories with 0700 perms and files with 0600 perms 😕 |
@sbwsg maybe its somethiung to do with my home directory being in a workspace mounted to a PV/PVC? |
Interesting, yeah I wonder if that's related. I noticed in another of your comments that the home directory has the setgid bit set on it ( |
@sbwsg Just hitting this. Is this something to be scheduled into next milestone? |
@StrongMonkey I cannot reproduce and as mentioned in an earlier comment we create the files with 0700 and 0600 perms. Can you provide any info to help try and reproduce this? What platform are you on? k8s version? tekton version? |
@sbwsg I am using the customized build of tekton which is based of v0.16.3. But as @itewk mentioned, I reproduced it by specifying the pod's runAsUser to 1000(non-root). I am cloning a private repo with ssh auth. Platform: rancher 2.5.4 There are multiple places which create files with 600 permission, this includes basic auth and ssh afaik. |
So, I just want to clarify what behaviour you're seeing. Here's an example TaskRun I run in my minikube: kind: TaskRun
apiVersion: tekton.dev/v1beta1
metadata:
name: test
spec:
serviceAccountName: ssh-key-service-account
taskSpec:
steps:
- name: foo
image: alpine:3.12
securityContext:
runAsUser: 1000
script: |
ls -lah $HOME/.ssh When I fetch the logs from this I see the following:
Can you paste the logs from running the same thing in your cluster? Edit to add: you'll need to create the ssh-key-service-account with a tekton ssh key too. |
The issue is due to
|
Hi @boxboatmatt thanks for jumping in. I don't think that's the issue here but appreciate your input. The files are being created in the original issue description with permissions 664 ( I haven't yet seen any clear pointer to what it is Tekton Pipelines should be doing differently. What I need is a short reproducible example that demonstrates the incorrect behaviour so I can debug it. |
@sbwsg not sure about the original issue the author was experiencing. I should have clarified that I believe the issue @StrongMonkey is experiencing is due to the rancher/gitjob use case for tekton, which mounts a git client secret on the Tekton container. For reference: |
I think I figured out the problem. This is happening when I think there is a bug in the workaround to make ssh respect Does that look correct? @sbwsg |
I'm still not sure what error you're facing 😆 Can you please describe the error message or incorrect behaviour that you are seeing?
We have some documentation on working with a HOME environment variable as a non-root user here: https://github.com/tektoncd/pipeline/blob/master/docs/auth.md#using-secrets-as-a-non-root-user But I can't tell if what you're describing is buggy or working-as-intended without knowing what the actual problem you're experiencing is 😄 |
@sbwsg oh I missed the doc reference, thanks for that! I was just reading through the symlink code and figure out if this could be a problem. I am just tracking down into this method which does the symlink function. So if |
Issues go stale after 90d of inactivity. /lifecycle stale Send feedback to tektoncd/plumbing. |
Stale issues rot after 30d of inactivity. /lifecycle rotten Send feedback to tektoncd/plumbing. |
Rotten issues close after 30d of inactivity. /close Send feedback to tektoncd/plumbing. |
@tekton-robot: Closing this issue. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
i guess this died on the vine? |
Expected Behavior
When the .ssh/* files are copied into the home dir of the runAsUser of the container they should have the expected standard .ssh file permissions
Actual Behavior
And because the permissions on
.ssh/config
are not 644 I get an error from git about about permissions on that file.Steps to Reproduce the Problem
Additional Info
Kubernetes version:
Output of
kubectl version
:Tekton Pipeline version:
Output of
tkn version
orkubectl get pods -n tekton-pipelines -l app=tekton-pipelines-controller -o=jsonpath='{.items[0].metadata.labels.version}'
Workaround
I added the following to my ClusterTask
The text was updated successfully, but these errors were encountered: