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

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

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

There's a closed pull request on the void-packages repository

xbps-triggers:system-accounts: use grep to check for user/group existent
https://github.com/void-linux/void-packages/pull/24754

Description:
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.