Bug 229936
| Summary: | [patch] Make net/openntpd coexist with new ntpd user added to base freebsd | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Ports & Packages | Reporter: | Ian Lepore <ian> | ||||
| Component: | Individual Port(s) | Assignee: | Christian Weisgerber <naddy> | ||||
| Status: | Closed FIXED | ||||||
| Severity: | Affects Some People | CC: | pi | ||||
| Priority: | --- | ||||||
| Version: | Latest | ||||||
| Hardware: | Any | ||||||
| OS: | Any | ||||||
| Attachments: |
|
||||||
(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. 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. 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 I moved _ntp to a different numerical UID. |
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).