Bug 229936 - [patch] Make net/openntpd coexist with new ntpd user added to base freebsd
Summary: [patch] Make net/openntpd coexist with new ntpd user added to base freebsd
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: Christian Weisgerber
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-07-21 21:00 UTC by Ian Lepore
Modified: 2018-08-03 20:42 UTC (History)
1 user (show)

See Also:


Attachments
Patch for compatibility with base ntpd user (1.70 KB, patch)
2018-07-21 21:00 UTC, Ian Lepore
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Ian Lepore freebsd_committer 2018-07-21 21:00:05 UTC
Created attachment 195345 [details]
Patch for compatibility with base ntpd user

Openntpd creates a user:group of _ntp:_ntp with ids 123:123.  The base system now has an ntpd user with those numeric ids and a different home dir.

Pass the --with-privsep-user=ntpd arg to configure on newer freebsd systems, and make a runtime check for chroot dir permissions compatible with the way freebsd base configures the ntpd home dir (owned by ntpd not root).
Comment 1 Christian Weisgerber freebsd_committer 2018-08-02 14:48:43 UTC
(Sorry, I wasn't aware of this PR until today.)

The purpose of the base system ntpd user is to provide elevated privileges (compared to joe average user), e.g. the ability to set the clock. It also has a home directory it can write in.

As part of OpenNTPD's privsep architecture, the point of the _ntp user is that it has no special privileges and the process running as _ntp gets chrooted into a directory it cannot even write to.

If we want to reuse the ntpd user for OpenNTPD, we need to revoke its privileges, e.g. by setting security.mac.ntpd.enabled=0 in the rc.d script. I don't know what to do about the discrepant home directory permissions, maybe chown the directory in the rc.d script as well.

Given that the ntpd and _ntp users are largely at cross-purposes, I think we should not reuse the ntpd user for OpenNTPD at all. Flipping privileges for the ntpd user between running base ntpd and OpenNTPD only makes things more complicated and brittle.

I suggest that the ntpd and _ntp users should continue to exist as separate users. I'll look into what's required to move _ntp to a different numerical UID.
Comment 2 Ian Lepore freebsd_committer 2018-08-02 20:47:20 UTC
My main thought is that openntpd is so flawed that nobody should ever use it for any reason.  The only reason that might have existed previously is that it runs with reduced privs (well, part of it does) and you couldn't easily run the real ntpd that way on freebsd.  Now that reason is gone.

That said, I'll just note that the mac_ntpd policy is already not enabled by default.  A sysadmin has to either compile it into a custom kernel, or specifically ask for it to be loaded in loader.conf, or the rc.d script for the stock ntpd will auto-load it.  The stock rc.d/ntpd script won't load it if openntpd is in use instead, and if the sysadmin has enabled mac_ntpd, the openntpd rc.d script absolutely should not undo that.  If openntpd needs a directory to chroot into that isn't writeable and isn't used for anything, /var/empty might be a good candidate.
Comment 3 commit-hook freebsd_committer 2018-08-03 20:30:39 UTC
A commit references this bug:

Author: naddy
Date: Fri Aug  3 20:29:53 UTC 2018
New revision: 476321
URL: https://svnweb.freebsd.org/changeset/ports/476321

Log:
  Move the numerical ID for the "_ntp" user, required for net/openntpd's
  privilege separation, after its value was usurped by the new "ntpd"
  user in 12.0-CURRENT.

  PR:		229936

Changes:
  head/GIDs
  head/UIDs
  head/UPDATING
  head/net/openntpd/Makefile
Comment 4 Christian Weisgerber freebsd_committer 2018-08-03 20:42:00 UTC
I moved _ntp to a different numerical UID.