search

wolfcw / libfaketime

libfaketime modifies the system time for a single application
https://github.com/wolfcw/libfaketime
GNU General Public License v2.0
2.62k stars 319 forks source link

libfaketime does not intercept adjtimex system call. #457

Open Ibasquare opened 5 months ago

Ibasquare commented 5 months ago

Problem

While running a podman container and attempting to execute a chronyd daemon within it, we encountered an unexpected behavior related to libfaketime. It appears that libfaketime is not intercepting the adjtimex system call, causing failure of execution of the chrony daemon.

Steps to Reproduce

  1. Launch a podman container (ubi8-based).
  2. Install libfaketime within the container with command make -j16 install FAKETIME_COMPILE_CFLAGS="-DFAKE_SETTIME"
  3. Configure environment to enable libfaketime at system-wide level export LD_PRELOAD="/usr/local/lib/faketime/libfaketime.so.1"
  4. Start a chronyd daemon inside the container.

Result:

adjtimex(0x8001) failed : Operation not permitted

wolfcw commented 5 months ago

It's correct that adjtimex() is not intercepted by libfaketime (yet). However, I assume that chronyd only calls adjtimex() due to its faketime settings, and that it basically a permissions issue of the container. Not sure how libfaketime should handle this when intercepting adjtimex().

Ibasquare commented 5 months ago

From the source code (https://gitlab.com/chrony/chrony/-/blob/master/sys_timex.c), it looks calling adjtimex() is the default behavior of the chrony daemon for applying small clock step.

BTW, I just did the same test on a ubi7 container using ntpd as a ntp daemon and everything works properly (using the same permissions).

Regarding the behavior of libfaketime regarding the adjtimex() system call, a quick fix would be to perform the same as in the adjtime() function (clock jump instead of gradually adjusting the clock with a separate thread as mentioned in the code - libfaketime.c, line 4002).