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?
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.
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.
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.
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.
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
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.
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.