Container application ownership and users

Technical Support
, , , ,
1

Hi all,

I have a question regarding Docker container/applications and ownership. I currently have 2 containers running, one based on the CMake vscode template, another based on the Slint rust template. (running on TorizonOS 7)
I got a permission denied error on when trying to access a unix socket from the Slint application, so I had a look at how the application is started inside the container. What I found is that my application in the slint based container is running as torizon user, while the application which is based on the cmake template runs as root.
So now I have the following questions:

  1. Where is the user actually set?
  2. Is this the same when using the vscode inline debugging, deploying the release (via vscode extension) and when starting the application from the docker compose (having the container added in the TorizonCore builder)?
  3. We do not want to give the applications root access, so we probably want to have a separate group which has access to the unix socket. What would be the easiest way to achieve in a docker environment? Can I somehow do this in my docker-compose (where I have all my containers specified) in the Torizoncore builder?

Best regards

Tim

2

Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!

Did you like my answer?

:+1: :-1:

Hello!

Managing user permissions and hardware access within Docker containers on a Toradex system running Torizon can be effectively handled using Linux cgroups and Docker configurations. Here’s a guide to help you set this up:

  1. User Permissions in Containers:
    User permissions are managed through Linux cgroups, which organize process access permissions to kernel resources. This can be used to manage container access permissions to hardware. You can find more details in the Toradex documentation.

  2. Container Permissions and Access:
    Docker containers operate in an isolated environment from the host OS. To grant hardware access, permissions must be explicitly set at runtime using Docker Run commands or Docker Compose files. More information is available here.

  3. Managing Group Access to Unix Sockets:
    If you encounter issues with Docker socket permissions, you can add your application user to the appropriate group and set the group ID in your Dockerfile. For example:

    RUN groupadd docker -g 990  && \
    usermod -a -G docker torizon

    This approach is discussed in the Toradex community.

  4. Container Access to System Resources:

    • Use the --device-cgroup-rule option to allow access to devices with specific major and minor numbers.
    • Use the --device option for more granular access control to specific devices.

    These settings can be configured in your Docker Compose file using device_cgroup_rules and devices configurations. More details can be found here.

Please remember that running containers in privileged mode (--privileged) grants all capabilities to containers and should be avoided in production systems for security reasons.

I hope this helps you manage your container permissions effectively!

Best regards,
Toradex AI Assistant.

Please, also check if these links can help you solve your problem:

Permission error in .NET dev container.

3

Greetings @TimSiegrist,

Where is the user actually set?

Is this the same when using the vscode inline debugging, deploying the release (via vscode extension) and when starting the application from the docker compose (having the container added in the TorizonCore builder)?

So this one is kind of a “it depends” type of answer.

If you are running the debug version through our extension then the user that executes the application is controlled by the torizon_run_as setting found in your project’s settings.json file.

If you are running the release version then it depends on your Dockerfile. The executing user will be whatever the last USER statement was in the Dockerfile: Dockerfile reference | Docker Docs

If your Dockerfile does not have an explicit USER statement, then it’s whatever the last USER statement was in the base container images that your Dockerfile is sourcing. If you trace it all the way back and there was no USER statements ever, not even in the base container images then it defaults to the root user.

So in your case let’s look. For the cmake template I see the base container image is torizon/debian:4 as per: vscode-torizon-templates/cmakeConsole/Dockerfile at dev · torizon/vscode-torizon-templates · GitHub

Let’s look at the source container image for this from our other repo here: torizon-containers/base/Dockerfile at stable · torizon/torizon-containers · GitHub

We see there is no explicit USER statement, therefore it defaults to root, which is what you observe.

Now for the slint rust template. I can see the base container image here is torizon/wayland-base-imx8:4. Looking at the source for this I also can’t see any explicit USER statement: torizon-containers/wayland-base/Dockerfile at stable · torizon/torizon-containers · GitHub

So actually I’m a little confused myself how the torizon user is set as the default user in your case. Unless you’re running it under debug, which as I said earlier uses torizon_run_as which defaults to torizon user.

We do not want to give the applications root access, so we probably want to have a separate group which has access to the unix socket. What would be the easiest way to achieve in a docker environment? Can I somehow do this in my docker-compose (where I have all my containers specified) in the Torizoncore builder?

Just to clarify. This is some socket file I assume, correct?

Off the top of my head I suppose when the socket file is created, you could create it so that it has permissions that allow it to be used by the user that will be accessing it. For example if the torizon user will access the socket you could create the socket with wide permissions, or permissions specifically for the torizon user. Maybe something along the lines like this would be helpful: Permission for -v /var/run/docker.sock - Docker Desktop - Docker Community Forums

Best Regards,
Jeremias

4

Hi @jeremias.tx

Yes, its mainly about a unix socket file. We made it work using root as user in the Slint container, which is working for us (for now). We will probably switch to some specific (a bit more restricted) user later on.
Thanks a lot for the explanations!

Best regards

Tim

5

Glad I was able to help clarify on this topic.

Best Regards,
Jeremias