Why does chrony need to be started as root?

I asked that question on #97546. It would be nice to fix and remove the tmpfiles rule instead. However I created this as the quick fix that we know works. It is weird because the config does give chrony a capability, but then runs as root anyways.

Hm. What's weird is that I'm running chrony on two systems (on 20.03) and I don't see this issue. Both instances have /var/lib/chrony/chrony.drift files which changed yesterday, so they're definitely being written to. The folders belong to chrony on both systems. Since it's dropping privileges (-u chrony) this really shouldn't be a problem.

Hmm, that's odd. The documented behaviour of StateDirectory is clearly to chown that directory to root. At first I thought that having that file owned by chrony would be enough but I don't think it is because chrony does a create+rename to write it. So unless it has a less safe fallback for when it doesn't have permissions it would fail if that directory every got chowned to root. I am quite curious how it is working on your system. Does your chronyd.service file have the StateDirectory= set?

Since it's dropping privileges (-u chrony) this really shouldn't be a problem.

I'm not quite sure I understand. Do you mean that it shouldn't be a problem not running as root because it drops privileges anyways or it shouldn't be a problem to write that file because it is started as root?

I'm not quite sure I understand. Do you mean that it shouldn't be a problem not running as root because it drops privileges anyways or it shouldn't be a problem to write that file because it is started as root?

Yeah… that was some faulty logic on my part, sorry.

In fact, my chronyd.services do not have StateDirectory set, because I'm on 20.03 and it was only introduced by @flokli in f25a301/#73934.

As for why chronyd runs as root in the first place, they seem to have a check for that, which can be bypassed as such:

  chrony = super.chrony.overrideAttrs (oA: {
    configureFlags = (oA.configureFlags or []) ++ [ "--with-pidfile=/run/chrony/chrony.pid" "--chronyrundir=/run/chrony" ];

    postPatch = ''
      ${oA.postPatch or ""}

      substituteInPlace main.c --replace 'LOG_FATAL("Not superuser")' '((void)0)'
    '';
  });

Where the configureFlags might not be strictly necessary.

With all that said, I'd say we could merge this as a quick fix, but in the long run it would definitely be better to not run this as root, in the first place.

I see. That all makes sense then. I propose the following:

1. Merge this as the fix for now. If you approve I will merge.
2. Contact the chrony devs to update to not check for root.
3. If they are unresponsive we can consider patching crhony, however I would prefer to stick to upstream as possible.

Can you link the upstream issue (or mail archive or whatever they have) here, once you've contacted them?

@kevincox as part of cleanup can we delete this branch now?

@ajs124 I filed #97718 to track the root issue.