In message <20250312074100.17f51ecf414b2084def58...@dec.sakura.ne.jp>,
Tomoaki
AOKI writes:
> On Tue, 11 Mar 2025 12:21:03 -0700
> Cy Schubert <cy.schub...@cschubert.com> wrote:
>
> > In message <20250312041554.48013af3d18e4a5672de3...@dec.sakura.ne.jp>,
> > Tomoaki
> > AOKI writes:
> > > On Tue, 11 Mar 2025 12:08:10 -0700
> > > Cy Schubert <cy.schub...@cschubert.com> wrote:
> > >
> > > > In message <20250312040101.154420f993ed27966dfc1...@dec.sakura.ne.jp>,
> > > > Tomoaki
> > > > AOKI writes:
> > > > > On Tue, 11 Mar 2025 08:13:51 -0700
> > > > > Cy Schubert <cy.schub...@cschubert.com> wrote:
> > > > >
> > > > > > In message <20250311011257.dd642ecbcd132ecb7142d...@dec.sakura.ne.j
> p>,
> > > > > > Tomoaki
> > > > > > AOKI writes:
> > > > > > > On Mon, 10 Mar 2025 16:37:58 +0100
> > > > > > > "Herbert J. Skuhra" <herb...@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.
>
> 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.schub...@cschubert.com>
> > FreeBSD UNIX: <c...@freebsd.org> Web: https://FreeBSD.org
> > NTP: <c...@nwtime.org> Web: https://nwtime.org
> >
> > e^(i*pi)+1=0
>
>
> --
> Tomoaki AOKI <junch...@dec.sakura.ne.jp>
--
Cheers,
Cy Schubert <cy.schub...@cschubert.com>
FreeBSD UNIX: <c...@freebsd.org> Web: https://FreeBSD.org
NTP: <c...@nwtime.org> Web: https://nwtime.org
e^(i*pi)+1=0
