Re: heads up: mac_ntpd has to be explicitly loaded in recent stable/14
Date: Wed, 12 Mar 2025 12:18:06 UTC
On Tue, 11 Mar 2025 17:08:46 -0700 Cy Schubert <Cy.Schubert@cschubert.com> wrote: > In message <20250312074100.17f51ecf414b2084def5820e@dec.sakura.ne.jp>, > Tomoaki > AOKI writes: > > On Tue, 11 Mar 2025 12:21:03 -0700 > > Cy Schubert <Cy.Schubert@cschubert.com> wrote: > > > > > In message <20250312041554.48013af3d18e4a5672de3ffd@dec.sakura.ne.jp>, > > > Tomoaki > > > AOKI writes: > > > > On Tue, 11 Mar 2025 12:08:10 -0700 > > > > Cy Schubert <Cy.Schubert@cschubert.com> wrote: > > > > > > > > > In message <20250312040101.154420f993ed27966dfc1b40@dec.sakura.ne.jp>, > > > > > Tomoaki > > > > > AOKI writes: > > > > > > On Tue, 11 Mar 2025 08:13:51 -0700 > > > > > > Cy Schubert <Cy.Schubert@cschubert.com> wrote: > > > > > > > > > > > > > In message <20250311011257.dd642ecbcd132ecb7142dc35@dec.sakura.ne.j > > p>, > > > > > > > Tomoaki > > > > > > > AOKI writes: > > > > > > > > On Mon, 10 Mar 2025 16:37:58 +0100 > > > > > > > > "Herbert J. Skuhra" <herbert@gojira.at> wrote: > > > > > > > > > > > > > > > > > On Mon, 10 Mar 2025 13:06:25 +0100, David Wolfskill wrote: > > > > > > > > > > > > > > > > > > > > On Mon, Mar 10, 2025 at 01:51:40PM +0200, Marek Zarychta wrot > > e: > > > > > > > > > > > Hello List Subscirbers, > > > > > > > > > > > > > > > > > > > > > > in the past the module was loaded automatically upon NTPD s > > erve > > > > r st > > > > > > artu > > > > > > > > p. > > > > > > > > > > > It's no longer true, now it has to be loaded earlier. > > > > > > > > > > > Perhaps people running stable/14 might find this message us > > eful > > > > . > > > > > > > > > > > > > > > > > > Hmm, works for me on main and stable/14. > > > > > > > > > > > > > > > > > > > So... I noticed this for (precisely) one of the five machines > > I h > > > > ave > > > > > > > > > > that track stable/14 -- the other 4 get mac_ntpd loaded autom > > agic > > > > ally > > > > > > as > > > > > > > > > > usual. > > > > > > > > > > > > > > > > > > > > In the failing case, it seems that > > > > > > > > > > > > > > > > > > > > sysctl security.mac.version > > > > > > > > > > > > > > > > > > > > yielded > > > > > > > > > > > > > > > > > > > > sysctl: unknown oid 'security.mac.version' > > > > > > > > > > > > > > > > > > I only get this if I build a kernel without "options MAC". But > > in t > > > > his > > > > > > > > > no mac_* kernel modules are built and ntpd fails with: > > > > > > > > > > > > > > > > > > Starting ntpd. > > > > > > > > > daemon control: got EOF > > > > > > > > > /etc/rc.d/ntpd: WARNING: failed to start ntpd > > > > > > > > > > > > > > > > In this case, you'll find something like > > > > > > > > Need MAC 'ntpd' policy enabled to drop root privileges > > > > > > > > daemon child exited with code 255 > > > > > > > > in ntpd logfile (/var/db/ntpd.log in my case, but > > > > > > > > possibly /var/log/messages by default). > > > > > > > > > > > > > > I don't understand why some systems (those in this thread) have a p > > robl > > > > em > > > > > > > not loading mac_ntpd while others, i.e. my stable/14 at $JOB, are f > > ine. > > > > I'd > > > > > > > > > > > > > like to try to understand the differences between those that work a > > nd t > > > > hose > > > > > > > > > > > > > that don't. > > > > > > > > > > > > > > First of all, the ntpd rc script bails without saying why when it > > > > > > > encounters a problem. can_run_nonroot() simply returns a bad return > > cod > > > > e > > > > > > > leaving us to wonder why. > > > > > > > > > > > > > > The first order of business is to produce a patch to indicate why > > it > > > > > > > bails. Please apply the attached patch and let me know where it fai > > ls. > > > > > > > Messages will be printed to stderr and to /var/log/messages (assumi > > ng > > > > > > > daemon.err is sent there). > > > > > > > > > > > > The output after patch (without loading mac_ntpd.ko manually): > > > > > > > > > > > > Mar 12 03:27:35 ***** rc.d/ntpd[2581]: user cannot access files > > > > > > listed in command line, exiting > > > > > > Mar 12 03:27:35 ***** root[2589]: /etc/rc: WARNING: failed to start n > > tpd > > > > > > > > > > > > See > > > > > > https://lists.freebsd.org/archives/dev-commits-src-branches/2025-Fe > > brua > > > > ry/0 > > > > > > 21308.html > > > > > > for my options related with ntpd. > > > > > > > > > > Is this before ntpd -u commit was reverted or after? > > > > > > > > Before revert. As I don't pull updates after I read your post which > > > > included the patch. > > > > > > > > > > > > > Please grep ntpd /etc/rc.conf. > > > > > > > > Result stripping comments. > > > > > > > > % grep ntpd /etc/rc.conf > > > > ntpd_flags="-4 -g -x -f /var/db/ntp/ntpd.drift -l /var/log/ntpd.log" > > > > > > This is your problem. Remove the -f and -l arguments and put the logfile > > > and driftfile ntp.conf statements instead. > > > > Wait, another way that works?! > > So I should consider it as a bug in ntpd. > > If the statements in ntpd.conf works, command line options should work > > just the same way (usually, if configuration files and command line > > option has the same functionalities, command line option is preferred > > to override, like /etc/make.conf and `make` command line).\ > > No, this is not a bug in ntpd. > > rc(8) issues, > su ntpd /usr/sbin/ntpd ... ntpd args > > If files are owned by root ntpd may not have access to them and it will > fail to start. > > If we do, > /usr/sbin/ntpd -u ntpd:ntpd ... other ntpd args > > ntpd will start as root, open its files, then setuid(ntpd) to change the > account it's running under. This is how we, FreeBSD, have implemented it. > This is an artifact of rc(8). And this is why we need mac_ntpd.ko. Because > ntpd -u will initiate its use of the clock, then switch to the ntpd UID. > The su ntpd /usr/sbin/ntpd approach starts ntpd under the ntpd account from > the very start. We need the kernel module in this case. > > I will rework the ntpd rc script to a) not use the rc(8) plumbing and b) > chroot itself. Both of these are better security than we currently have. > > The patch was the first step in deprecating mac_ntpd and the first step to > putting ntpd into its own chroot. > > What you have described is not a bug but an artifact how we invoke ntpd > under FreeBSD, specifically the su. Tried (still before reverting, patched /etc/rc.d/ntpd) switching command line option to corresponding statements in ntp.conf, and encountered strange behavior. In /etc/rc.conf (this time, not stripped commented out lines), ===== Quote ===== % grep ntpd /etc/rc.conf # ntpd_program="/usr/local/sbin/ntpd" # ntpd_flags="-4 -g -x -f /var/db/ntpd.drift -p /var/run/ntpd.pid -l /var/log/ntpd.log" # ntpd_flags="-4 -g -x -f /var/db/ntpd.drift -l /var/log/ntpd.log" # ntpd_flags="-4 -g -x -f /var/db/ntp/ntpd.drift -l /var/log/ntpd.log" ntpd_flags="-4 -g -x" # ntpd_config="/usr/local/etc/ntp.conf" ntpd_config="/etc/ntp/ntp.conf" ntpd_enable="YES" ntpd_sync_on_start="YES" # Sync time on ntpd startup, even if offset is high daily_ntpd_leapfile_enable="YES" # Automatically fetch leapfile daily. ntp_db_leapfile="/var/db/ntp/ntpd.leap-seconds.list" % ===== End quote ===== Note that ports ntpd is no longer installed now (remnant when I tried ports version before). /etc/ntp/ntp.conf, which is specified in /etc/rc.conf, now contains: ===== Quote ===== driftfile "/var/db/ntp/ntpd.drift" logfile "/var/log/ntpd.log" leapfile "/var/db/ntp/ntpd.leap-seconds.list" ===== End quote ===== And commented out 'mac_ntpd_load="YES"' line in /boot/loader.conf, cased (in /var/log/messages, essential part only): ===== Quote ===== ntpd 4.2.8p18-a (150): Starting Command line: /usr/sbin/ntpd -4 -g -x -p /var/db/ntp/ntpd.pid -c /etc/ntp/ntp.conf -f /var/db/ntp/ntpd.drift -u ntpd:ntpd -g (snip) switching logging to file /var/log/ntpd.log daemon child exited with code 255 /etc/rc: WARNING: failed to start ntpd (snip) ntpd 4.2.8p18-a (150): Starting Command line: /usr/sbin/ntpd -4 -g -x -p /var/db/ntp/ntpd.pid -c /etc/ntp/ntp.conf -f /var/db/ntp/ntpd.drift -g switching logging to file /var/log/ntpd.log ===== End quote ===== Strangely, ntpd is invoked twice, and command line shown in /var/log/messages still contains deleted options. The second run successfully invoked ntpd, even though mac_ntpd.ko is not auto-loaded. # service ntpd stop works, but following # service ntpd start fails without `kldload mac_ntpd`. For other configurations in /etc/rc.conf, comments (after "#") are sanely treated as comments (as behaviors indicates), but this result seems to indicate that comments are NOT treated as comments. Quite strange. > > Anyway, I'll try it once the ongoing heavy rebuilds finished. > > > > > > > > > > > ntpd_config="/etc/ntp/ntp.conf" > > > > ntpd_enable="YES" > > > > ntpd_sync_on_start="YES" > > > > daily_ntpd_leapfile_enable="YES" > > > > % > > > > > > > > > > > > > -- > > > Cheers, > > > Cy Schubert <Cy.Schubert@cschubert.com> > > > FreeBSD UNIX: <cy@FreeBSD.org> Web: https://FreeBSD.org > > > NTP: <cy@nwtime.org> Web: https://nwtime.org > > > > > > e^(i*pi)+1=0 > > > > > > -- > > Tomoaki AOKI <junchoon@dec.sakura.ne.jp> > > > -- > Cheers, > Cy Schubert <Cy.Schubert@cschubert.com> > FreeBSD UNIX: <cy@FreeBSD.org> Web: https://FreeBSD.org > NTP: <cy@nwtime.org> Web: https://nwtime.org > > e^(i*pi)+1=0 -- Tomoaki AOKI <junchoon@dec.sakura.ne.jp>