W dniu 10.03.2025 o 14:04, Tomoaki AOKI pisze:
On Mon, 10 Mar 2025 14:21:32 +0200
Marek Zarychta <zarych...@plan-b.pwste.edu.pl> wrote:
W dniu 10.03.2025 o〓14:17, Tomoaki AOKI pisze:
On Mon, 10 Mar 2025 05:06:25 -0700
David Wolfskill <da...@catwhisker.org> wrote:
On Mon, Mar 10, 2025 at 01:51:40PM +0200, Marek Zarychta wrote:
Hello List Subscirbers,
in the past the module was loaded automatically upon NTPD server startup.
It's no longer true, now it has to be loaded earlier.
Perhaps people running stable/14 might find this message useful.
Cheers
....
So... I noticed this for (precisely) one of the five machines I have
that track stable/14 -- the other 4 get mac_ntpd loaded automagically as
usual.
In the failing case, it seems that
sysctl security.mac.version
yielded
sysctl: unknown oid 'security.mac.version'
which thus caused the code in /etc/rc.d/ntpd:
# Try to set up the MAC ntpd policy so ntpd can run with reduced
# privileges. Detect whether MAC is compiled into the kernel, load
# the policy module if not already present, then check whether the
# policy has been disabled via tunable or sysctl.
[ -n "$(sysctl -qn security.mac.version)" ] || return 1
sysctl -qn security.mac.ntpd >/dev/null || kldload -qn mac_ntpd ||
return 1
[ "$(sysctl -qn security.mac.ntpd.enabled)" == "1" ] || return 1
(in can_run_nonroot()) to return before the kldload can run.
As the (only) machine that exhibits the failure is the one that
acts as my Internet gateway, I am fairly reluctant to have it down
longer than necessary. :-}
(I admit that I was beginning to wonder if what I seemed to be
seeing was actually real.)
Peace,
david
--
David H. Wolfskill da...@catwhisker.org
Thank you, Claude Malhuret.
https://wickedemerald.wordpress.com/2025/03/08/speech-from-claude-malhuret/
See https://www.catwhisker.org/~david/publickey.gpg for my public key.
FYI:
https://lists.freebsd.org/archives/dev-commits-src-branches/2025-February/021308.html
https://lists.freebsd.org/archives/dev-commits-src-branches/2025-February/021313.html
https://lists.freebsd.org/archives/dev-commits-src-branches/2025-February/021312.html
https://lists.freebsd.org/archives/dev-commits-src-branches/2025-February/021315.html
https://lists.freebsd.org/archives/dev-commits-src-branches/2025-March/021327.html
Maybe order of some evaluations in /etc/rc.d/ntpd needs to be moved.
It looks like the problem is here:
+ eval ' limits -C daemon〓〓 /usr/sbin/ntpd〓 -p /var/db/ntp/ntpd.pid -c
/etc/ntp.conf〓 -u ntpd:ntpd'
+ limits -C daemon /usr/sbin/ntpd -p /var/db/ntp/ntpd.pid -c
/etc/ntp.conf -u ntpd:ntpd
daemon control: got EOF
+ _return=255
+ umask 0022
+ [ 255 -ne 0 ]
+ [ -z '' ]
+ return 1
+ warn 'failed to start ntpd'
--
Marek Zarychta
Yes. Newly added "-u" option mandates mac_ntpd.ko to drop root
priviledge.
Maybe line 48 through 55
https://cgit.freebsd.org/src/tree/libexec/rc/rc.d/ntpd?h=stable/14#n48
of the /etc/rc.d/ntpd would better relocated to after line 68 or
removed. Not tried, though, but this conditional causes the function
to be return to caller before auto-loading mac_ntpd.ko at line 62
through 68.
Another option would be relocating line 62 through 68 to the top of
the function can_run_nonroot().
Yes, the offending commit is 1a241a911dc8635c3803f1a6620e1ab4692f6ecf
(cherry picked from commit 521f66715afb312b356afafc68cbc044a436a753).
Starting and stopping services in 14/stable and main are done in a
different manner, I have not investigated it much though.
Anyway, it seems like unintentional change, aka regression in stable/14 ...
Cheers
--
Marek Zarychta
