Bug 525828 – Update enewuser/enewgroup phase suggestions

• Product: Documentation
• Status: RESOLVED OBSOLETE

[Description Michael Orlitzky 2014-10-19 00:51:38 UTC]

(Mostly repeating my comment on bug #217042)

The devmanual suggests using pkg_setup for new users and groups. It seems like pkg_preinst is preferred, unless there is some necessity for pkg_setup. The devmanual should explain why we generally prefer pkg_preinst, and list the exceptions where pkg_setup is required.

First suggestion, https://devmanual.gentoo.org/ebuild-writing/functions/pkg_preinst/index.html:

  Adding users and groups. However, since pkg_preinst may be called after 
  src_compile, pkg_setup is the more suitable location for user creation
  — see Users and Groups. 

Second suggestion, https://devmanual.gentoo.org/ebuild-writing/users-and-groups/index.html:

  Regardless of whether you are adding a group or a user, this should be 
  performed in the pkg_setup function: pkg_setup is sandbox-safe, is called 
  before the compile process so a build that requires the user to exist will 
  have it, and is also called for both binary and source packages.

[Comment 1 Markos Chandras (RETIRED) 2014-11-15 10:59:53 UTC]

Patch? :)

[Comment 2 Michael Orlitzky 2014-11-22 13:47:38 UTC]

Created attachment 390050 [details, diff]
update-the-wording-in-common-pkg_preinst-tasks.patch

[Comment 3 Michael Orlitzky 2014-11-22 13:48:13 UTC]

Created attachment 390052 [details, diff]
update-pkg_preinst-pkg_setup-text-in-users_and_groups.patch

[Comment 4 Michael Orlitzky 2014-11-22 13:48:55 UTC]

TWO patches!

[Comment 5 Mike Gilbert 2017-12-16 22:17:49 UTC]

I would argue that pkg_postinst is often better than pkg_preinst.

Doing it in pkg_preinst would only be necessary of some of the installed files are owned by the new user. And in that case, pkg_setup is probably better since the ownership is likely set in the src_install phase.

In many cases the new user does not own any installed files, and is only referenced at runtime by things like init scripts; pkg_postinst works fine for that.

[Comment 6 Michael Orlitzky 2017-12-16 23:21:53 UTC]

(In reply to Mike Gilbert from comment #5)
> I would argue that pkg_postinst is often better than pkg_preinst.

I don't remember, but I probably used preinst because that's what was mentioned in bug 217042. In fact, postinst may be strictly preferable, because the new user won't be created if installation fails due to e.g. a file collision.

Does anyone see a downside to postinst with respect to preinst?

[Comment 7 Ulrich Müller 2017-12-17 02:35:50 UTC]

(In reply to Michael Orlitzky from comment #6)
> (In reply to Mike Gilbert from comment #5)
> > I would argue that pkg_postinst is often better than pkg_preinst.

Why?

> I don't remember, but I probably used preinst because that's what was
> mentioned in bug 217042. In fact, postinst may be strictly preferable,
> because the new user won't be created if installation fails due to e.g. a
> file collision.

Except that collision checks take place *before* pkg_preinst is called.

> Does anyone see a downside to postinst with respect to preinst?

If the ebuild needs to do any adjustments of file ownership in the image dir, then this is only possible if the owner already exists in the pkg_preinst phase.

Also, the package should not be merged if user or group creation fails.

[Comment 8 Mike Gilbert 2017-12-17 07:39:59 UTC]

(In reply to Ulrich Müller from comment #7)
> > (In reply to Mike Gilbert from comment #5)
> > > I would argue that pkg_postinst is often better than pkg_preinst.
> 
> Why?

Please read the rest of my comment for my arguments. I wrote three paragraphs and you only quoted the first.

> > I don't remember, but I probably used preinst because that's what was
> > mentioned in bug 217042. In fact, postinst may be strictly preferable,
> > because the new user won't be created if installation fails due to e.g. a
> > file collision.
> 
> Except that collision checks take place *before* pkg_preinst is called.
> 
> > Does anyone see a downside to postinst with respect to preinst?
> 
> If the ebuild needs to do any adjustments of file ownership in the image
> dir, then this is only possible if the owner already exists in the
> pkg_preinst phase.

The package manager only needs to do adjustments of file ownership if the ebuild installed files in src_install with some owner other than root. In this case, I would expect pkg_setup to be used for creating the user in the first place.

As I previously stated, it is much more common for the new user to be used only at runtime, not at merge time.

> Also, the package should not be merged if user or group creation fails.

This is a valid concern. I suppose pkg_preinst is better from that perspective.

[Comment 9 Michael Orlitzky 2017-12-17 14:29:04 UTC]

(In reply to Ulrich Müller from comment #7)
> 
> Except that collision checks take place *before* pkg_preinst is called.

For a more mundane example, the user could simply hit Ctrl-C before the merge.


> Also, the package should not be merged if user or group creation fails.

That's a pretty good reason though.

[Comment 10 Michael Orlitzky 2019-07-22 17:03:22 UTC]

All of these issues are addressed in a much cleaner way by GLEP 81.