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

[bobdoah]

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

2. 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

[douglasparker]

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

[bobdoah]

@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]

@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]

I have opened PR #182 to solve this.

[bobdoah]

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

[JtMotoX]

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]

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