🐋 <Running Docker Container As Non-Root>

[polskikrol]

Is there an existing issue for this?

• I have searched the existing issues

Does this issue exist in the latest version?

• I'm using the latest release

Describe the bug?

When I attempt to run a container with the UID and GID of the arm user on the docker host, I receive errors.

Here is the addition to my docker-compose.yml file --- user: '1002:1003'.

Here is the error:

PermissionError: [Errno 13] Permission denied: '/etc/container_environment'
*** Killing all processes...
Traceback (most recent call last):
  File "/sbin/my_init", line 414, in <module>
    main(args)
  File "/sbin/my_init", line 330, in main
    import_envvars(False, False)
  File "/sbin/my_init", line 90, in import_envvars
    for envfile in listdir("/etc/container_environment"):
  File "/sbin/my_init", line 74, in listdir
    return sorted(os.listdir(path))

I have the docker image running perfect as the root user with Intel QSV acceleration, however, trying to see if its possible to run this in a more secure manner.

To Reproduce

See description.

Built from source files ?

• I Built the image from source

What architecture are you seeing the problem on?

amd64

Expected behavior?

Should be able to run as a non-root user.

Relevant log output

No response

Anything else?

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[microtechno9000]

What are the permissions for the mounted volumes?

[polskikrol]

What are the permissions for the mounted volumes?

They are all owned by the host user 'arm' part of group 'arm'. I used these respective UID and GID to pass into the container. The actual files shared as volumes were chown arm:arm recursively, including the hidden files.

Here is the docker file that works. When I try to uncomment the user statement, it breaks with the error mentioned in the original post.

version: '3.8'
services:
  arm:
    image: 'arm/arm-qsv:latest'
    container_name: 'arm'
    hostname: 'arm'
    networks:
      docker_bridge:
        ipv4_address: '172.16.0.3'
#    user: '1002:1003' 
#    group_add:
#      - '109' # host render group id
    environment:
      - ARM_UID=1002
      - ARM_GID=1003
      - TZ=America/New_York
    volumes:
      - /docker/arm/files/arm:/home/arm
      - /docker/arm/files/logs:/home/arm/logs
      - /docker/arm/files/media:/home/arm/media
      - /docker/arm/files/music:/home/arm/music
      - /docker/arm/files/config:/etc/arm/config
    devices:
      - /dev/sr0:/dev/sr0 
      - /dev/dri/renderD128:/dev/dri/renderD128
      - /dev/dri/card0:/dev/dri/card0
    ports:
      - '8080:8080' # port for web interface
    privileged: true
    restart: 'unless-stopped'
    build:
      context: '/docker/arm'
      dockerfile: 'dockerfile' 
networks:
  docker_bridge:
    external: true

Using a custom build which only installs the required tools and compiles the code needed to enable Intel Quicksync. Not other modifications to any scripts or anything. Using current tag docker image.

[Migsi]

I've encountered some similar issues when trying to get it running on my TrueNAS host. There is a project "Truecharts" providing apps as Kubernetes Helm charts. They provide ARM too, which is basically the docker container wrapped into a Helm chart and some glue configs for a "pretty" config UI. Since a while their CI for updates of the container seems to fail due to the inacessability of the home directory for user "arm", which in their case gets mapped to "apps" (UID/GID 568). AFAIK noone over there looked at the issue (yet), but I highly doubt the PVC mounted as home for user "arm" was set with the wrong permissions, as they strictly stick to some common settings for all apps they provide, ensuring functional setups (at least in that regard).
My current (but now quite old) install was from a time where this didn't happen. But I've encountered some issues when trying to mount the arm home directory as a hostpath volume. Even when setting ownership and access rights 1:1 as in the container without hostpath, the container just seemed to "hide" the volume mapping and write to nirvana. I did some research on how docker handles it when a path inside a container already exists with subdirectories, but gets mapped to some external volume. Following their docs, something like this is supposed to happen, which leads me to believe the ordering of directory creation within the container might be messed up/cause this issue.
It still could be the two issues I've just described are completely unrelated, in which case I apologize and will open a dedicated ticket 😅

[microtechno9000]

At the moment, there has been limited testing with use of Docker-Compose, although I have started doing some work on that for V3.0 in the dev branch.

Currently ARM requires root permissions for the access required to the system host. As far as I am aware, we have limited the permissions where we can, but some root access is required.

If you can get ARM working and reduce the permissions please do, and raise a PR or post the propose changes here. As always, reducing permissions to those only required is important.

[polskikrol]

That does answer quite a few questions :) I use docker-compose with pretty much everything, so happy to test out things as we get close with development.

If I find spots to reduce the permissions, to eventually get to running everything as a regular user, will certainly submit information.

[TheRealGramdalf]

One thought I had about this is the issue with mounting devices - according to my research CAP_SYS_ADMIN is required because of the mount call. By default, docker blocks all mount calls within containers, and the only way to prevent that is to add back the permission - which in this case happens to be CAP_SYS_ADMIN. This is a problem because that permission is overloaded; it essentially gives full system access.

The mount call in question is (as far as I'm aware) required for ripping - I recall something about being able to disable a setting with the limitation of only being able to rip data of a certain type, but I don't remember exactly. One technique that's actually in use in ARM right now is using /etc/fstab to allow regular users to mount a disk, except it is blocked by docker unless CAP_SYS_ADMIN is granted. My thought was this: rather than running mount within the container, what if it was run outside, and the directory bind mounted in? This should be doable with the use of some udev rules and fstab, and while it would require some host system modifications, I believe it would be a good tradeoff - running in docker already does some host system modification (adding the arm user etc), and most ARM systems are going to be a dedicated machine which is configured explicitly for that purpose.

Just a thought, sorry if I didn't explain it properly.

[Migsi]

[...] and most ARM systems are going to be a dedicated machine which is configured explicitly for that purpose.

While I agree on your idea in general and see the benefits, I don't agree on most ripping machines being dedicated hardware. As this got available as an "app" on TrueNAS (as stated in my previous comment), more and more people will use it as such. But relying on docker external host mods will completely break the setup for those. So I'd say doing that is not really an option :/