Bug 199127

Summary: rc.d/ntpd: user-set ntpd_flags stomps over rc-defined ones (pidfile, driftfile)
Product: Base System Reporter: Jeremy Chadwick <jdc>
Component: confAssignee: Ian Lepore <ian>
Status: In Progress ---    
Severity: Affects Many People CC: crees, freebsd, giunti, ian, rc
Priority: ---    
Version: 9.2-STABLE   
Hardware: Any   
OS: Any   
See Also: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230561
Description Flags
Use command_args not rc_flags to avoid rc.conf messing up configuration none

Description Jeremy Chadwick 2015-04-02 21:36:28 UTC

Use of ntpd_flags in /etc/rc.conf results in completely broken behaviour when ntpd starts.  The most common issue is that there is no longer a pidfile associated with ntpd, as well as other problems.

This is caused by a design/logic problem in etc/rc.d/ntpd which I have not yet worked out.  I am certain it must be easy/simple, and hoping someone in the FreeBSD team can figure it out easier than I can.


rc.conf contains following settings:


Process starts as:

/usr/sbin/ntpd -g -c /conf/ME/ntp.conf -p /var/run/ntpd.pid -f /var/db/ntpd.drift

Add the following line to rc.conf:


Process starts as:

/usr/sbin/ntpd -g -c /conf/ME/ntp.conf -4

Note missing -p and -f.  This causes lots of problems (like service/rc scripts saying "ntpd: no such pid", etc.).

This is on a stable/9 system (9.3-STABLE, which is not a choice in the Bugzilla pulldown for some reason).  No idea if stable/10 has this fixed (haven't looked, but if it has, it should be MFC'd).

Footnote: this may or may not somehow be related to Bug 106927.
Comment 1 Harald Glatt 2017-06-28 20:16:50 UTC
Just wanna mention that I just stumbled across this and it's still present in FreeBSD 11.0-RELEASE-p10.
Comment 2 Chris Rees freebsd_committer 2017-08-30 13:02:50 UTC
Created attachment 185920 [details]
Use command_args not rc_flags to avoid rc.conf messing up configuration

I've come across this bug too, but only realised after seeing this one :)

On my machine the pidfile doesn't appear because I've overridden ntpd_flags in rc.conf.

The correct use is to have command_args for non-configurable stuff, not (ab)use ${name}_flags and hope no-one changes them!

Please would someone approve me to commit this?


Comment 3 Ian Lepore freebsd_committer 2018-06-28 22:16:15 UTC
I have incorporated the command_args fix suggested in comment 2 and the attached patch into a larger set of changes, see https://reviews.freebsd.org/D16050
Comment 4 Ian Lepore freebsd_committer 2018-06-28 22:18:24 UTC
*** Bug 177089 has been marked as a duplicate of this bug. ***
Comment 5 commit-hook freebsd_committer 2018-07-20 13:59:56 UTC
A commit references this bug:

Author: ian
Date: Fri Jul 20 13:59:30 UTC 2018
New revision: 336547
URL: https://svnweb.freebsd.org/changeset/base/336547

  Automatically run ntpd as non-root when possible.

  Ntpd needs only a subset of full root privileges to do its job. Specifically
  it needs the ability to manipulate system time, and to re-bind to a
  privileged UDP port after interface changes. The mac_ntpd(4) policy module
  (see r336525) can grant these privs.

  These changes detect the availability of mac_ntpd(4). If enabled, and if the
  ntpd configuration is fairly vanilla, it automatically runs ntpd as the
  non-root user 'ntpd' (uid 123). "Vanilla" means the config doesn't include
  command line or ntp.conf options changing the location of files or using any
  files/dirs likely to be inaccessible to user ntpd.  Ntpd can still run as
  non-root when using such options, but the admin must ensure all required
  files and dirs are accessible, and then set ntpd_user=ntpd in rc.conf.

  Note that these changes also address PR 199127 by using the command_args
  technique suggested in the patch. They also tangentially address PR 113552,
  which is primarily about inconsistent filenames in documentation, but some
  of the inconsistancy was caused by old code in rc.d/ntpd which is leftover
  from the intial import from netbsd. There was code to do chroot setup which
  required the use of the netbsd clockctl(4) device; that code never had any
  effect on freebsd, because we lack that device and don't build ntpd with the
  options that would allow using it.

  PR:		113552 199127
  Relnotes:	yes
  Differential Revision:	https://reviews.freebsd.org/D16050

Comment 6 Jeremy Chadwick 2018-08-29 06:19:48 UTC
Ian, is r336547 potentially MFC-able to stable/11, or a portion of it, re: c#2?
Comment 7 Ian Lepore freebsd_committer 2018-08-29 13:41:04 UTC
(In reply to Jeremy Chadwick from comment #6)

I would like to mfc the entire set of run-nonpriv changes, but adding the ntpd user was very disruptive for 12-current users, and I'm afraid it's likely to be just as disruptive if not moreso for 11-stable users (especially anyone running openntpd, which also adds a uid 123).  I definitely plan to revisit the issue and see what can be done to smooth the transition, but it needs some coordination with re@ and the ports team (and I'm very busy with $work right now), so it might be best to wait until after 12.0-RELEASE is done.