Github messages for voidlinux
 help / color / mirror / Atom feed
From: sgn <sgn@users.noreply.github.com>
To: ml@inbox.vuxu.org
Subject: Re: [PR PATCH] [Updated] xbps-triggers:system-accounts: use grep to check for user/group existent
Date: Thu, 10 Sep 2020 03:03:30 +0200	[thread overview]
Message-ID: <20200910010330.T39EIuINp_QX7P0jSHooWHyFCT_4VAofsvc8Izf5KxU@z> (raw)
In-Reply-To: <gh-mailinglist-notifications-41a7ca26-5023-4802-975b-f1789d68868e-void-packages-24754@inbox.vuxu.org>

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

There is an updated 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: 4947 bytes --]

From 1618b92815be217c50ccda0513df02cefaa143d2 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.

While we're at it, sanity check for `system_groups` and `system_accounts`
specification.
---
 srcpkgs/xbps-triggers/files/system-accounts | 28 ++++++++++++++-------
 srcpkgs/xbps-triggers/template              |  3 +--
 2 files changed, 20 insertions(+), 11 deletions(-)

diff --git a/srcpkgs/xbps-triggers/files/system-accounts b/srcpkgs/xbps-triggers/files/system-accounts
index d48e9b7a2cf..fc1a563a239 100755
--- a/srcpkgs/xbps-triggers/files/system-accounts
+++ b/srcpkgs/xbps-triggers/files/system-accounts
@@ -19,6 +19,12 @@ export PATH="usr/sbin:usr/bin:/usr/sbin:/usr/bin:/sbin:/bin"
 group_add() {
 	local _grname _gid use_gid
 
+	case "$1" in
+	*:*:*)	echo "Invalid system_groups specification"
+		exit 1
+		;;
+	esac
+
 	_grname="${1%:*}"
 	_gid="${1#*:}"
 
@@ -26,7 +32,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 +65,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 +73,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
@@ -80,6 +83,13 @@ run)
 
 		# System user/group required by a package.
 		for acct in ${system_accounts}; do
+
+			case "$acct" in
+			*:*:*)	echo "Invalid system_accounts specification"
+				exit 1
+				;;
+			esac
+
 			_uname="${acct%:*}"
 			_uid="${acct#*:}"
 
@@ -96,8 +106,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 +119,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
diff --git a/srcpkgs/xbps-triggers/template b/srcpkgs/xbps-triggers/template
index b28d198b1ce..f6325c5f569 100644
--- a/srcpkgs/xbps-triggers/template
+++ b/srcpkgs/xbps-triggers/template
@@ -1,8 +1,7 @@
 # Template file for 'xbps-triggers'
 pkgname=xbps-triggers
 version=0.116
-revision=1
-archs=noarch
+revision=2
 bootstrap=yes
 short_desc="XBPS triggers for Void Linux"
 maintainer="Enno Boland <gottox@voidlinux.org>"

  parent reply	other threads:[~2020-09-10  1:03 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-08  0:40 [PR PATCH] " sgn
2020-09-08  1:29 ` ericonr
2020-09-08 12:04 ` sgn
2020-09-09  1:07 ` [PR PATCH] [Updated] " sgn
2020-09-09 14:04 ` sgn
2020-09-10  0:37 ` ahesford
2020-09-10  0:57 ` sgn
2020-09-10  1:03 ` sgn [this message]
2020-09-10  1:17 ` ahesford
2020-09-10  6:54 ` the-maldridge
2020-09-10  7:04 ` ericonr
2020-09-10  7:09 ` ericonr
2020-09-10 13:06 ` sgn
2020-09-10 13:48 ` ahesford
2020-09-10 13:53 ` sgn
2020-09-10 13:57 ` ericonr
2020-09-10 14:01 ` sgn
2020-09-10 14:01 ` [PR PATCH] [Closed]: " sgn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200910010330.T39EIuINp_QX7P0jSHooWHyFCT_4VAofsvc8Izf5KxU@z \
    --to=sgn@users.noreply.github.com \
    --cc=ml@inbox.vuxu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).