Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 693050 - net-misc/openntpd with acct-user/ntp: ntpd fails to start because HOME was set to /dev/null
Summary: net-misc/openntpd with acct-user/ntp: ntpd fails to start because HOME was se...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Paul B. Henson
URL:
Whiteboard:
Keywords: PullRequest
Depends on:
Blocks:
 
Reported: 2019-08-29 05:49 UTC by Lars Wendler (Polynomial-C) (RETIRED)
Modified: 2019-12-28 04:54 UTC (History)
7 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Lars Wendler (Polynomial-C) (RETIRED) gentoo-dev 2019-08-29 05:49:24 UTC
ntpd from openntpd simply terminates on startup attempt when acct-user/ntp sets HOME for ntp user to /dev/null. openntpd ebuilds expect HOME to be /var/lib/openntpd/chroot
Comment 1 Mike Gilbert gentoo-dev 2019-08-29 12:59:12 UTC
It should probably use a different user account to avoid conflicts with net-misc/ntp.
Comment 2 Thomas Deutschmann (RETIRED) gentoo-dev 2019-08-29 16:44:33 UTC
Didn't Michael mentioned that case in his "[gentoo-dev] RFC: GLEP81 home directory guidelines" mail?
Comment 3 Michael Orlitzky gentoo-dev 2019-08-29 17:30:24 UTC
Yeah, the openntpd ebuild sets

  NTP_HOME="${NTP_HOME:=/var/lib/openntpd/chroot}"

and then relies on that path existing:

  econf \
    --with-privsep-user=ntp \
    --with-privsep-path=${NTP_HOME} ...

I have a feeling it doesn't care about the home directory at all, but I'm on my way out the door and don't have time to check. Instead, the openntpd ebuild should probably be doing

  keepdir /var/lib/openntpd/chroot

with the appropriate permissions and ownership in diropts. If the package needs a path, it shouldn't count on the acct-user package coincidentally creating it as ACCT_USER_HOME.

If that works, no separate account is needed.
Comment 4 Michael Orlitzky gentoo-dev 2019-08-29 17:43:38 UTC
Nevermind, the INSTALL file says,

  --with-privsep-path=path
	ntpd will always use the home directory of the privsep user
	to chroot to, but specifying this parameter will change the
	post-installation checks and instructions to match the specified path.

Unless there's a good reason to try to share the same user between the two daemons, a separate user is probably the way to go. Gotta run for real now,
Comment 5 Paul B. Henson 2019-08-29 18:37:46 UTC
I've noticed the discussion of the new user/group handling mechanism on the dev list, but I think it's above my proxy-maintainer pay grade :). Let me know what you want me to change to resolve this, or feel free to update the user/group handling stuff to your satisfaction directly.

Thanks...
Comment 6 Michael Orlitzky gentoo-dev 2019-08-30 13:58:20 UTC
Understood Paul =)

I think the best solution here is to switch the openntpd username and group from "ntp" to "openntpd".

This conflict already existed -- the net-misc/ntp ebuilds have always created the "ntp" user with home directory set to /dev/null. And net-misc/openntpd has always fought about it:

  pkg_setup() {
    ...
	# make sure user has correct HOME ...
		esethome ntp "${NTP_HOME}"
    ...
  }

Before GLEP81, this happened to work, because the "enewuser" command run by net-misc/ntp would *not* switch the home directory back to what it originally was (/dev/null). The new acct-user packages do, so the "ntp" user's home directory will occasionally be reset to /dev/null, and that of course breaks openntpd.

The fact that it *really* doesn't work now just highlights the fact that maybe we shouldn't have tried to share the same user for two different packages in the first place. It was never great to have the home directory for the net-misc/ntp daemon's user set to /var/lib/openntpd/chroot, for example.

So, tl;dr, do what Mike said and use "openntpd" as your user/group from now on. This will require some tweaks to the ebuild, but will also allow you to drop the esethome hack used above. With two separate users for two separate daemons, there's no need to fight over a home directory.
Comment 7 Paul B. Henson 2019-08-31 01:19:37 UTC
Ok. Should I just update the ebuild as is with the new user/group, or do I need to switch to using the new design that depends on separate acct-user/openntpd and acct-group/openntpd ebuilds to create the user/group? Right now the uid/gid are random, not statically set.
Comment 8 Michael Orlitzky gentoo-dev 2019-08-31 21:44:07 UTC
(In reply to Paul B. Henson from comment #7)
> Ok. Should I just update the ebuild as is with the new user/group, or do I
> need to switch to using the new design

You can switch the username first and then migrate to the new GLEP81 user-packages later if that's easier.
Comment 9 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2019-09-01 05:33:34 UTC
(In reply to Michael Orlitzky from comment #8)
> (In reply to Paul B. Henson from comment #7)
> > Ok. Should I just update the ebuild as is with the new user/group, or do I
> > need to switch to using the new design
> 
> You can switch the username first and then migrate to the new GLEP81
> user-packages later if that's easier.

However, please request fixed UID/GID and make sure to include it in enewuser/enewgroup calls to save users from having to update later on.
Comment 10 Paul B. Henson 2019-09-08 02:59:39 UTC
What's the process for getting a reserved fixed uid/gid? I posted on the dev list but nobody responded.
Comment 11 Michael Orlitzky gentoo-dev 2019-09-09 13:55:59 UTC
(In reply to Paul B. Henson from comment #10)
> What's the process for getting a reserved fixed uid/gid? I posted on the dev
> list but nobody responded.

Practically, it's best to pick one and then post to the list asking if anyone sees a problem with your choice. That way, if no one responds, you can assume that it's OK to proceed.

Since ntp has taken uid/gid 123, might I suggest uid/gid 321 for openntpd?

Neither Fedora nor Arch has already assigned that uid/gid, and neither of them have an "openntpd" user or group with another ID, so I don't see any immediate problems with it.
Comment 12 Paul B. Henson 2019-09-27 00:37:47 UTC
Ok, here's a pull request:

https://github.com/gentoo/gentoo/pull/13051

Let me know if anything else needs fixing.

Is there a particular timeline desired for migrating ebuilds to the new user/group depends mechanism?
Comment 13 Michael Orlitzky gentoo-dev 2019-10-02 18:35:58 UTC
(In reply to Paul B. Henson from comment #12)
> 
> Is there a particular timeline desired for migrating ebuilds to the new
> user/group depends mechanism?

The new way is a lot better, so "as soon as possible," but we'll be migrating for years so there's no need to stress about it.
Comment 14 Larry the Git Cow gentoo-dev 2019-12-08 10:08:37 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e499d09c6711bad8dfaba4b1640e1a2be6f78057

commit e499d09c6711bad8dfaba4b1640e1a2be6f78057
Author:     Paul B. Henson <henson@acm.org>
AuthorDate: 2019-11-26 05:03:46 +0000
Commit:     Joonas Niilola <juippis@gentoo.org>
CommitDate: 2019-12-08 10:08:15 +0000

    net-misc/openntpd: EAPI=7, Use GLEP 81 for user/group instead of user eclass
    
    Bug: https://bugs.gentoo.org/693050
    Signed-off-by: Paul B. Henson <henson@acm.org>
    Closes: https://github.com/gentoo/gentoo/pull/13763
    Signed-off-by: Joonas Niilola <juippis@gentoo.org>

 net-misc/openntpd/openntpd-6.2_p3-r1.ebuild | 66 +++++++++++++++++++++++++++++
 1 file changed, 66 insertions(+)