title: File permission in docker container with volume mount
body: <p>I'm trying to let a docker container access a letsencrypt certificate from the host file system.</p>
  
  <p>I do not want to run the docker container as root, but rather as a user with very specific access rights.
  Neither do I want to change the permissions of the certificate.
  All I want, is for the given user, to have access to read the certificate inside the docker container.</p>
  
  <p>The certificate has the following setup:</p>
  
  <pre><code>-rw-r----- 1 root cert-group
  </code></pre>
  
  <p>The user who's going to run the docker container, is in the cert-group:</p>
  
  <pre><code>uid=113(myuser) gid=117(myuser) groups=117(myuser),999(cert-group),998(docker)
  </code></pre>
  
  <p>This works as long as we're on the host - I am able to read the file as expected with the user "myuser".</p>
  
  <p>Now I want to do this within a docker container with the certificate mounted as a volume. 
  I have done multiple test cases, but none with any luck.</p>
  
  <p>A simple docker-compose file for testing:</p>
  
  <pre><code>version: '3.7'
  
  services:
  
    test:
      image: alpine:latest
      volumes:
        - /etc/ssl/letsencrypt/cert.pem:/cert.pem:ro
      command: &gt; 
        sh -c 'ls -l / &amp;&amp; cat /etc/passwd &amp;&amp; cat /etc/group &amp;&amp; cat /cert.pem'
      user: "113:117"
      restart: "no"
  </code></pre>
  
  <p>This ouputs a lot, but most important is:</p>
  
  <pre><code>test_1  | -rw-r-----    1 root     ping          3998 Jul 15 09:51 cert.pem
  test_1  | cat: can't open '/cert.pem': Permission denied
  test_1  | ping:x:999:
  </code></pre>
  
  <p>Here I assume that "ping" is an internal group for docker alpine, however, im getting some mixed information about how this collaborates with the host.</p>
  
  <p>From this article <a href="https://medium.com/@mccode/understanding-how-uid-and-gid-work-in-docker-containers-c37a01d01cf" rel="nofollow noreferrer">https://medium.com/@mccode/understanding-how-uid-and-gid-work-in-docker-containers-c37a01d01cf</a> my takeaway is, that there's a single kernel handling all permissions (the host) and therefore if the same uid and gid is used, the permissions would inherit from the host. However, even though that the running user is 113:117, which on the host is part of the group 999 it still doesnt give me access to read the file.</p>
  
  <p>Next I found this article <a href="https://medium.com/@nielssj/docker-volumes-and-file-system-permissions-772c1aee23ca" rel="nofollow noreferrer">https://medium.com/@nielssj/docker-volumes-and-file-system-permissions-772c1aee23ca</a> where especially this bullet point caught my attention:</p>
  
  <blockquote>
    <p>The container OS enforces file permissions on all operations made in
    the container runtime according to its own configuration. For example,
    if a user A exists in both host and container, adding user A to group
    B on the host will not allow user A to write to a directory owned by
    group B inside the container unless group B is created inside the
    container as well and user A is added to it.</p>
  </blockquote>
  
  <p>This made me think, that maybe a custom Dockerfile was needed, to add the user inside docker, and make the user part of 999 (which is known as ping as earlier stated):</p>
  
  <pre><code>FROM alpine:latest
  RUN adduser -S --uid 113 -G ping myuser
  USER myuser
  </code></pre>
  
  <p>Running this gives me the exact same result, now with myuser appended to passwd though:</p>
  
  <pre><code>test_1  | myuser:x:113:999:Linux User,,,:/home/myuser:/sbin/nologin
  </code></pre>
  
  <p>This is just a couple of things that I've tried.</p>
  
  <p>Another is syncing /etc/passwd and /etc/group with volumes found in some other blog</p>
  
  <pre><code>volumes:
    - /etc/passwd:/etc/passwd
    - /etc/group:/etc/group
  </code></pre>
  
  <p>This makes it visually look correct inside the container, but it doesnt change the end result - still permission denied.</p>
  
  <p>Any help or pointers in the right direction would be really appreciated since I'm running out of ideas.</p>