Re: [PR PATCH] [Closed]: xbps-triggers: make system-accounts behave in altroots

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

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

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

xbps-triggers: make system-accounts behave in altroots
https://github.com/void-linux/void-packages/pull/24812

Description:
This attempts to fix some issues uncovered in #24754. The changes:
- Use `command -v` to check for `groupadd`, `usermod`, `useradd` and `passwd` rather than looking for executable files at a fixed path, to match what the shell will actually do when these programs are invoked.
- Uses the `-P|--prefix` options to `groupadd`, `usermod` and `useradd`, as well as the `-R|--root` option to `passwd`, to manipulate files in the target root (which should be `.`) rather than on the host system.
- Skips `getent` altogether, instead letting the `useradd` and `groupadd` programs detect and do the right thing when attempting to create existing users or groups (`getent` is still used in the `pre-remove` hook to try to extract the GECOS field for an account, but this is a non-critical operation and we can tolerate pulling the wrong comment in some edge cases in `xbps-remove -r`).

As a bonus, I cleaned up the hook output a bit, avoiding some strange text artifacts when user or group IDs are unspecified.

There are ~200 packages that specify system accounts or groups. I've tested this on a few that seem to offer a range of different user/group styles:
- sndio (system account with primary group `audio`, tests account creation with no user group)
- dbus (system account with specific UID, tests account creation with user group of matching GID)
- kismet (system group only, no user group)
- pulseaudio (system account with matching group, system group, additional groups for account)
- rtkit (system account with matching group)

These packages were installed on the local host by the superuser, and were also installed by an unprivileged user into an alternate root owned by that user; some packages were also installed to the unprivileged root by the superuser. In all cases, the hooks seem to correctly update `etc/passwd` and `etc/group` with respect to creating, disabling and reenabling accounts.

I have no means to test functionality on a system using a remote directory service but these changes at least prevent an altroot installation from leaking account creation or modification into the local host files while also ensuring that the account modifications are made in the altroot.

cc: @void-linux/pkg-committers @ericonr