Skip to content

git-clone fails over SSH fails with 'No user exists for uid 65532' #1341

@antsareeverywhere

Description

@antsareeverywhere

Expected Behavior

Following the README results in successful clones of git repos.

Actual Behavior

/ko-app/git-init, git clone, and ssh all fail with the error 'No user exists for uid 65532'.

Steps to Reproduce the Problem

  1. Install version 0.10 of git-clone using kubectl apply -f https://api.hub.tekton.dev/v1/resource/tekton/task/git-clone/0.10/raw
  2. Follow the README to set up a git-clone task with credentials provided either via the ssh-directory or provided via a k8s service account.
  3. Run the git-clone task
  4. The task will fail

Additional Info

This is a regression. For example, version 0.9 successfully clones over ssh.

There are a few things that combine to make it hard or impossible to get SSH to work with the default image:

  • (1) The image runs with runAsUser: 65532, which does not have a username associated with it.

  • (2) The base image (which I believe is a ko image) provides an /etc/passwd entry for the nobody user with uid 65534 and home directory /nonexistent. But that's not the user git-clone runs as.

  • (3) OpenSSH calls getpwuid to find the user based on their UID here. This hard-coded call is why the task fails.

  • (4) You can't add a username or modify the existing user because git-clone sets runAsNonRoot: true in the securityContext. Also the standard utilities like useradd and usermod do not exist on the container.

  • (5) You can't modify the task to run as the nobody user, because then SSH looks for the SSH config in /nonexistent despite git-clone setting the HOME environment variable to /home/git. You can tell SSH to look for a config in $HOME using ssh -F $HOME/.ssh/config, but git-clone doesn`t provide way to set a custom SSH command.

You can run git-clone as root by simply kubectl editing or patching the task and removing the security context. But that is not ideal.

Two recommendations:

  • (r1) since the run environment has changed a lot since the task was designed, communicate a unified approach running as non-root. If it's okay to have a UID and set $HOME, is it okay to have a real user? It's hard to tell as a user which parts of the interface are deliberate security decisions and which parts are working around limitations of the base image.

  • (r2) add an example and test for git clone over SSH since this will generally be an edge case and it will help users understand how to set up their own environments

Metadata

Metadata

Assignees

No one assigned

    Labels

    kind/bugCategorizes issue or PR as related to a bug.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions