[PR PATCH] xbps-triggers:system-accounts: use grep to check for user/group existent

[sgn <sgn@users.noreply.github.com>]

[-- Attachment #1: Type: text/plain, Size: 1765 bytes --]

There is a new pull request by sgn against master on the void-packages repository

https://github.com/sgn/void-packages xbps-triggres-system-account
https://github.com/void-linux/void-packages/pull/24754

xbps-triggers:system-accounts: use grep to check for user/group existent
In `system-accounts` triggers, we're using `getent(1)` to check whether
the username or group in question is existed before doing the heavy
lifting.

However, `getent(1)` will check the database in host system instead of our
rootfs, and by `PATH` manipulation logic, we prefer to use `usr/bin/getent`
inside our rootfs instead of host `getent(1)`.

This is usually not a problem since we mostly run `xbps-triggers` in
a real system instead of running from foreign system.

Except for `base-files` packages, which used to not have group `kvm`
pre-allocated. Thus, requires running this trigger, and lead to all sort
of problems:
- If host system is a musl-based linux system, with gcompat installed,
  and we're bootstrapping a glibc one, `getent(1)` will be executable,
  however, when `getent(1)` attempt to `dlopen(3)` other libraries,
  it'll run into failure.
- If host system doesn't have `kvm` group pre-allocated (bootstrapping
  from foreign distro), we attempt to run `groupadd(1)` on such system,
  thus failing with EPERM.

If we run into one of those cases, `xbps-reconfigure(1)` will stop
configuring `base-files`, not running `base-files`' `INSTALL` and leave
the system in half-baked state, without some requires files and
directories.

Switch to `grep(1)` to check for username and group existence,
since `passwd(5)` and `group(5)` is well-documented.

A patch file from https://github.com/void-linux/void-packages/pull/24754.patch is attached

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: github-pr-xbps-triggres-system-account-24754.patch --]
[-- Type: text/x-diff, Size: 3844 bytes --]

From 73d59167ed32631e3e9011d72c0e087ba172418f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=C4=90o=C3=A0n=20Tr=E1=BA=A7n=20C=C3=B4ng=20Danh?=
 <congdanhqx@gmail.com>
Date: Tue, 8 Sep 2020 07:12:30 +0700
Subject: [PATCH] xbps-triggers:system-accounts: use grep to check for
 user/group existent

In `system-accounts` triggers, we're using `getent(1)` to check whether
the username or group in question is existed before doing the heavy
lifting.

However, `getent(1)` will check the database in host system instead of our
rootfs, and by `PATH` manipulation logic, we prefer to use `usr/bin/getent`
inside our rootfs instead of host `getent(1)`.

This is usually not a problem since we mostly run `xbps-triggers` in
a real system instead of running from foreign system.

Except for `base-files` packages, which used to not have group `kvm`
pre-allocated. Thus, requires running this trigger, and lead to all sort
of problems:
- If host system is a musl-based linux system, with gcompat installed,
  and we're bootstrapping a glibc one, `getent(1)` will be executable,
  however, when `getent(1)` attempt to `dlopen(3)` other libraries,
  it'll run into failure.
- If host system doesn't have `kvm` group pre-allocated (bootstrapping
  from foreign distro), we attempt to run `groupadd(1)` on such system,
  thus failing with EPERM.

If we run into one of those cases, `xbps-reconfigure(1)` will stop
configuring `base-files`, not running `base-files`' `INSTALL` and leave
the system in half-baked state, without some requires files and
directories.

Switch to `grep(1)` to check for username and group existence,
since `passwd(5)` and `group(5)` is well-documented.
---
 srcpkgs/xbps-triggers/files/system-accounts | 15 ++++++---------
 1 file changed, 6 insertions(+), 9 deletions(-)

diff --git a/srcpkgs/xbps-triggers/files/system-accounts b/srcpkgs/xbps-triggers/files/system-accounts
index d48e9b7a2cf..f87fd0d9c03 100755
--- a/srcpkgs/xbps-triggers/files/system-accounts
+++ b/srcpkgs/xbps-triggers/files/system-accounts
@@ -26,7 +26,7 @@ group_add() {
 		use_gid="gid ${_gid}"
 	fi
 
-	if ! getent group ${_grname} >/dev/null; then
+	if ! grep -q "^${_grname}:" etc/group >/dev/null; then
 		if [ -n "$use_gid" ]; then
 			groupadd -r ${_grname} -g ${_gid} >/dev/null 2>&1
 		else
@@ -59,9 +59,6 @@ run)
 	if [ -x sbin/groupadd -o -x bin/groupadd ]; then
 		GROUPADD=1
 	fi
-	if [ -x bin/getent -o -x sbin/getent ]; then
-		GETENT=1
-	fi
 	if [ -x bin/passwd -o -x sbin/passwd ]; then
 		PASSWD=1
 	fi
@@ -70,8 +67,8 @@ run)
 	post-install)
 		# System groups required by a package.
 		for grp in ${system_groups}; do
-			if [ -z "$GROUPADD" -a -z "$GETENT" ]; then
-				echo "WARNING: cannot create ${grp} system group (missing groupadd/getent)"
+			if [ -z "$GROUPADD" ]; then
+				echo "WARNING: cannot create ${grp} system group (missing groupadd)"
 				echo "The following group must be created manually: $grp"
 				continue
 			fi
@@ -96,8 +93,8 @@ run)
 			[ "${_uid}" != "${_uname}" ] &&
 				use_id="-u ${_uid} -g ${pgroup:-${_uid}}"
 
-			if [ -z "$USERADD" -a -z "$GETENT" -a -z "$PASSWD" ]; then
-				echo "WARNING: cannot create ${acct} system user/group (missing useradd/getent/passwd)"
+			if [ -z "$USERADD" -a -z "$PASSWD" ]; then
+				echo "WARNING: cannot create ${acct} system user/group (missing useradd/passwd)"
 				echo "The following system account must be created:"
 				echo "   Account: ${uname:-${_uid}} (uid: '${_uid}')"
 				echo "   Description: '${descr}'"
@@ -109,7 +106,7 @@ run)
 
 			group_add ${pgroup:-${acct}}
 
-			if ! getent passwd ${_uname} >/dev/null; then
+			if ! grep -q "^${_uname}:" etc/passwd >/dev/null; then
 				useradd -c "$descr" -d "$homedir" -s "$shell" ${user_groups} \
 					${pgroup:+-N} ${use_id:=-g ${pgroup:-${_uname}}} -r ${_uname} && \
 					passwd -l ${_uname} >/dev/null 2>&1