How to set time from inside container

Hello,

I have a problem with setting system time and date from inside container. I run container with --cap-add sys_time parameter as root user (target solution is to use torizon user - root as temporary solution). I’ve added cap_sys_time capability to /bin/date. I can read date but while trying to set it I get permission denied:

root@1c3ee560e889:/etc# date
Fri Nov 28 01:07:43 UTC 2008
root@1c3ee560e889:/etc# date +%Y%m%d -s "20081128"
date: cannot set date: Operation not permitted
20081128

If I try to change date while running container with --priviliged parameter everything is fine. Any tips how to change date with unpriviliged container?

System: TorizonCore 5.4.0
Container image base: torizon/debian:2-bullseye

Greetings @Kacper,

Just to understand better. What exactly is the goal here?

Are you trying to sync the in-container time to the host system time?

or

Are you trying to dynamically changing the entire host system time from inside the container?

Is changing the time something you’ll only do once? Or will the app/system be changing the time multiple times through operation?

As a reference here’s a similar question here: Setting local time zone in Torizon containers

However this involves setting the time from outside of the container rather than inside the container. As for setting time from inside a container dynamically this might be tricker without using --privileged see this external thread for reference: How to set system time dynamically in a Docker container - Server Fault

But let me know what you’re trying to do and we can discuss possible solutions.

Best Regards,
Jeremias

Hi @jeremias.tx,

I am trying to dynamically change entire host system time from inside the container. This feature is meant to be used multiple times “on demand” triggered from other containers.

So unfortunatelly both referenced topics are not my use case.

Best regards,
Kacper

Hi @Kacper ,

since you want to change the host time from inside the container, have a look at the link. In the first answer, the user mentions the method of using ntpdate.

Here some more information about ntpdate.

Let us know if it worked.

Best Regards
Kevin

Hello @kevin.tx,

I saw this solution but It seems odd and not natural to me to use ntpdate to set host’s time from container this way. Especially because calling date/hwclock works perfectly on priviliged container (as a result time on host and inside the container are set). Both container and host are using the same Kernel namespace for this so there should be a possibility to tweak with it.

I did some testing and it appears that TorizonCore must limit somehow containers so that only priviliged containers can change time/date. I ran following commands on TorizonCore and on my PC in WSL:

docker run IMAGE_NAME date -s "10 FEB 1981 10:00:00"

as a result Permission denied on both systems, but

docker run --cap-add SYS_TIME IMAGE_NAME date -s "10 FEB 1981 10:00:00"

this works perfectly on WSL, but fails with permission denied on TorizonCore. I would highly appreciate some suggestions how can I achieve my goal on TorizonCore without using priviliged container.

Best Regards,
Kacper

Hi @kacper,
working on similar kind of issues, we’ve found that some integration around systemd between host and container can allow some operations from within the docker and requires the following volume bindings:

  • /var/run/dbus:/var/run/dbus:rw
  • /run/systemd/system:/run/systemd/system:rw
  • and debian packages libsystemd-dev:arm64 libsystemd0:arm64

Not exact sure about the packages, haven’t had time to investigate dependencies.

With better systemd host-container integration, you could be able to run timedatectl or start and stop systemd services, hope this helps, I’m interested about your feedback about that.
BR,
ldvp

Hello @ldvp,

Thanks for the reply. I’ve managed to handle changing time with your suggestions. I can use host’s systemd to change time with timedatectl.

Downside of this solution is losing some isolation between host and container so this might be potential security threat. What’s more this way I am limited to 1 second resolution which is not enough for me.

@kevin.tx, @jeremias.tx any updates on this topic? Maybe someone from TorizonCore development team might have some ideas what permissions/capabilities/other actions should be taken to provide permission to change time with ‘date’ (actually clock_settime() which is used by date and will be used by my C app) command from container. It is clear that it must be possible if privileged container is capable of performing this.

Best regards,
Kacper

Hi @Kacper !

There might be a way to help you. Please try the following.

  1. Download the default seccomp file from Docker:
wget https://raw.githubusercontent.com/moby/moby/master/profiles/seccomp/default.json -O /etc/docker/seccomp/time.json
  1. Edit the file to add the clock_settime64 syscall to it.
...
"names": [
    "settimeofday",
    "stime",
    "clock_settime",
    "clock_settime64"
],
"action": "SCMP_ACT_ALLOW",
...
  1. Start the container with this seccomp file, and the SYS_TIME capability.
$ docker run -it --cap-add=SYS_TIME --security-opt seccomp=/etc/docker/seccomp/time.json torizon/debian:2-bullseye
root@ddce364a7c52:/# date +%T -s "11:23:00"
11:23:00
root@ddce364a7c52:/# date

Those steps might help you to set the time from within a container without the need to deal with:

  • systemd,
  • root user, or
  • privileged container

Let me know if it works for you.

Best regards,

In addition to what Henrique has said I’ll offer an alternative approach. This may be a more or less hacky method depending on how you view things though.

So if you run a container with --network=host you can then SSH from the container to the host system via localhost. Via ssh you can then just invoke the commands to change the host time using the host itself. Again a bit of a roundabout method, but an alternative approach.

Best Regards,
Jeremias

Hi @henrique.tx,

Thank you very much for your example. It does exactly what I need. I’ve tested it and it works exactly as I would suspect.

Thank you all for help.

Best regards,
Kacper

Hi @Kacper !

Good to know that it helped you!

Also, if a message is the solution, please mark it as such.

Best regards,