Skip to content
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

Running as non-root user fails with "No module named 'requests'" #162

Open
bobdoah opened this issue Nov 26, 2023 · 7 comments · May be fixed by #163
Open

Running as non-root user fails with "No module named 'requests'" #162

bobdoah opened this issue Nov 26, 2023 · 7 comments · May be fixed by #163
Assignees

Comments

@bobdoah
Copy link

bobdoah commented Nov 26, 2023

Describe the bug
When running as non-root, the Docker image fails to run with:

Traceback (most recent call last):                                                                                                                                                                       
  File "/cloudflare-ddns.py", line 17, in <module>                                                                                                                                                         
    import requests                                                                                                                                                                                   
ModuleNotFoundError: No module named 'requests' 

This is because the directory where the dependencies are copied, /root/.local/, is not the user's home directory, and is inaccessible.

To Reproduce
Steps to reproduce the behavior:

  1. Using the Kubernetes manifest, add:
template:
   spec:
      securityContext:
         runAsUser: 1000
         runAsGroup: 1000
  1. Pod will fail to run

Expected behavior
The pod should run as non root. Ideally, a USER directive will be used in the Dockerfile, so runAsNonRoot: true can be used in preference to runAsUser and runAsGroup.

Introduced by the change to a multi-stage Docker build: #127

@bobdoah bobdoah linked a pull request Nov 26, 2023 that will close this issue
@douglasparker
Copy link

I just noticed that my docker container isn't working anymore due to this issue too.

@bobdoah
Copy link
Author

bobdoah commented Dec 20, 2023

@douglasparker I pushed my fork to DockerHub to unblock myself: https://hub.docker.com/repository/docker/bobdoah/cloudflare-ddns if it's not too difficult, you can use that. At least, until this is merged, or the fix undone.

@douglasparker
Copy link

@douglasparker I pushed my fork to DockerHub to unblock myself: https://hub.docker.com/repository/docker/bobdoah/cloudflare-ddns if it's not too difficult, you can use that. At least, until this is merged, or the fix undone.

Sweet deal, thanks for doing that! 😍

@JtMotoX
Copy link

JtMotoX commented Mar 25, 2024

I have opened PR #182 to solve this.

@bobdoah
Copy link
Author

bobdoah commented Mar 28, 2024

Thanks @JtMotoX, I'd already opened PR #163 but I'm not wedded to it.

@JtMotoX
Copy link

JtMotoX commented Mar 28, 2024

No disrespect @bobdoah but looks like yours is hard-coded to user 1000 and would break if run by another uid. Some Kubernetes policy engines (such as built-in OpenShift) will spin up the container with a random uid for security reasons. My PR will support running as any uid and the user can specify the uid:gid in their docker-compose or deployment.yaml.

@bobdoah
Copy link
Author

bobdoah commented Apr 4, 2024

No offense taken. I didn't envisage anyone running this on openshift or anything like that, as my use case is k3s.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants