System Time Setting through Docker Containers in Torizon with X11 access

I currently have a system of two docker containers to display a UI using a verdin imx8mplus running the Torizon OS.

The first docker container is a base wayland container as my graphical compositor. The second is a container that runs our application and communicates with the Wayland container to draw our UI. To allow for communication over X11 I have the second container running as a basic user and not as root.

We would like to add support for changing the system time of the device through the UI, I’ve confirmed that if I modify the container to run with root permissions I can set the system time, however I then lose the ability to use X11 and draw the UI with the Wayland container. When keeping the container running as a basic user I don’t have permissions to modify the system time and so far have not had any luck with adding in CAP_SYS_TIME to running my docker container.

Can someone point me in the right direction for how it is suggested to add in setting time while still supporting X11 in a docker container for the Torizon ecosystem?

Hi, I’m the Toradex AI Assistant.

I might make mistakes or occasionally get you wrong. Our support team will step in if needed.


I understand you need to set system time from your UI application while maintaining proper Wayland graphics communication. This is a common challenge when balancing security and functionality in containerized environments.

Recommended Approach: Avoid Running as Root

Based on Toradex best practices, running containers as root should be avoided when possible (1). The documentation states that you should “avoid running the container as privileged, especially in this scenario” and emphasizes using more granular capabilities and control group rules (1).

Solution: Use CAP_SYS_TIME Capability

The proper approach is to use the CAP_SYS_TIME capability, which you mentioned trying. Here’s how to implement it correctly:

Docker Run Command

Add the capability when starting your container:

docker run --cap-add CAP_SYS_TIME your-app-container

Docker Compose Configuration

In your docker-compose.yml:

services:
  your-app:
    image: your-app-image
    cap_add:
      - CAP_SYS_TIME

Wayland Communication Setup

For proper Wayland communication between containers, ensure you’re following the established pattern (2). Your containers should share the /tmp directory where Weston creates the Unix socket file:

volumes:
  - type: bind
    source: /tmp
    target: /tmp

(2)

Troubleshooting CAP_SYS_TIME

If CAP_SYS_TIME isn’t working as expected, verify:

  1. User Context: Ensure your application process has the capability when it attempts to set the time
  2. Container Runtime: Confirm the capability is properly inherited by your application process
  3. System Call: Use settimeofday() or clock_settime() system calls in your application

Alternative Architecture

Consider separating concerns by creating a dedicated time-setting service that runs with appropriate privileges, while keeping your UI container as a regular user. This service could communicate with your UI container through IPC mechanisms supported by Docker (3).

Could you share which version of Torizon OS you’re running? This will help me provide more specific guidance for your setup.

Best regards, Toradex AI Assistant.


Did you like my answer? :+1: :-1:

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

Greetings @belangen,

If I understand the core problem. You essentially have one use-case where root permissions are needed. You have another use-case where non-root permissions are needed. Meanwhile, a single container doesn’t particularly work well with mixed permissions.

My first impressions is to separate the functionality into two separate containers. Then, in theory you could have one container with root and one with non-root permissions.

Though you would need some kind of mechanism to communicate between the UI and time-setting containers. That said, there’s numerous ways to do this a common way is using a shared network to communicate between the containers. Something that Docker containers do fairly naturally: Networking | Docker Docs

Could also have a common shared directory between the two containers and share information that way.

I’m sure there are other ideas, but this is what came to mind immediately.

Best Regards,
Jeremias

Hi @belangen ,

Any updates for us here?

Best,