Re: [chrony-dev] Using Linux Capabilities

[Michael Cashwell <chronyd@xxxxxxxxxxxx>]

On Oct 27, 2017, at 9:17 AM, Miroslav Lichvar <mlichvar@xxxxxxxxxx> wrote:

> Capabilities are needed to bind to a privileged port and adjust the system clock, but chronyd does other things on start that require root privileges, e.g. create /var/{run,lib,log}/chrony, open /dev/pps*, /dev/ptp*, /dev/rtc and possibly other devices.

In my case I pass in paths for run and log files that do not need root and running in local mode without an RTC it seems to not access the other files listed. That may be blind luck but in practice no failures occur.

> As I understand it, the option you propose would change the behavior of the program.

Only if the proposed new optional argument is used. If omitted then the program's behavior is completely unchanged.

> Maybe it would help if you could explain in what cases it's useful to start chronyd without root privileges?

It may be that this use case is highly specialized, but here goes.

I have a set of processes running on an embedded system that runs in isolation and has no access to the Internet and thus any NTP time sources. One particular function that happens within these processes is the Linux system time is set from a specialized data source (over which I have no control) and *then* (and only then) is that time to be vended via NTP on the local LAN to all the subordinate hosts.

chronyd thus would not discipline the system time but simply accept it as-is. If I understand the terminology correctly that is called “local mode”.

Vending the system time before it has been set by the specialized data source would be a failure. The most obvious way to ensure that does not happen is to not start chronyd until the system time has been set, hence the idea for my process to exec chronyd. This is not so it can start and stop frequently (as was posited in another post) but only to have strict control over when NTP requests are answered.

Since my parent process has the desired capabilities and long since dropped root there’s no way for it to fork/exec chronyd as root, hence the idea to use capabilities only.

It sounds like a “more standard” approach would be:

1: chronyd is started by the OS at boot in local mode (eg: no upstream time sources) and in an inert state where it WILL NOT respond to NTP requests on the LAN because is has not been told that the system time is “good”.

2: At some point after boot up my parent process invokes chronyc (again as non-root) to bless the system time as good and thus enable NTP requests to be answered.

If that’s possible without source code changes that’s fine with me.

Thanks for your assistance!

-Mike


--
To unsubscribe email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "unsubscribe" in the subject.
For help email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "help" in the subject.
Trouble?  Email listmaster@xxxxxxxxxxxxxxxxxxxx.