-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
xbps-triggers:system-accounts: use grep to check for user/group existent #24754
Conversation
Remember to change the version / revbump the package. |
On 2020-09-07 18:29:26-0700, Érico Nogueira Rolim ***@***.***> wrote:
Remember to change the version / revbump the package.
Yup, I forgot to revbump (since no behavior changes).
Also, would wait for other's opinions.
|
73d5916
to
0058465
Compare
@void-linux/pkg-committers |
This is probably a fine replacement, depending on how much we care about sanity checks on values on group and user definitions. As a totally contrived example, suppose somebody puts an invalid value in The In the end, it seems like the system state would be the same either way, because either a valid group is created or already exists; an invalid group fails to match and the trigger tries unsuccessfully to create it; or an invalid group falsely matches and the trigger doesn't try to run a If we care about the failure always appearing when a group should be created but isn't, you might have to |
Minor correction: _grname=wheel:x
_gid=x:123
I believe we can do the sanity check for argument by: case "$1" in
*:*:*) echo "Invalid group specification" >&2; exit 1;;
esac
|
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.
0058465
to
1618b92
Compare
Looks good to me |
Just to point out that this can break in really hard to diagnose ways on systems that are configured with NSS. |
Could we instead make this trigger run only inside chroot (for the masterdir case, as well as installing new systems) and in a real system? Add some sort of early failure if |
On 2020-09-09 23:54:26-0700, Michael Aldridge ***@***.***> wrote:
Just to point out that this can break in really hard to diagnose
ways on systems that are configured with NSS.
Hm, I've never used such system.
I'm in a fence, now.
I'm not sure what to do now.
- Use both grep and getent to check
- ignore xbps-trigger's system-accounts outside of chroot
I'm really to prefer the second approach since it's the sanner
approach.
|
The more I look at this, the more I see breakage when populating an alternate root. Won't Ignoring If we really want to do this the "right" way, it's not obvious to me that the existence tests add value. For groups, just |
On 2020-09-10 06:48:52-0700, "Andrew J. Hesford" ***@***.***> wrote:
The more I look at this, the more I see breakage when populating an
alternate root. Won't `useradd`, `usermod` and `groupadd` always act
on the system root? These commands provide a `--root` option that
seems to redirect their actions in the way we want, but we aren't
using that option now. It's also not clear from their man pages how
well these commands get along with directory services.
Yes, it's broken.
Ignoring `system-accounts` unless `$ROOTDIR = /` like @ericonr
suggests is a reasonable way to avoid the worst of these issues. If
you go that route, the hook should at least print all of the users
and groups that should exist (along with ID numbers, if provided)
for the package to function as expected.
Agree.
If we really want to do this the "right" way, it's not obvious to me
that the existence tests add value. For groups, just `groupadd
--root ...` and catch the return code to know the difference between
a real failure and an attempt to create a group that already exists.
For users, just `useradd --root ...` and, if the return code
indicates that the username already exists, try `usermod --root ...`
instead.
Hm, I think we need `groupadd --prefix` and `useradd --prefix` instead.
|
Wouldn't all of this still be broken if messing with a device that uses NSS? afaik that would require a proper service and all |
Yeah, this PR is fundamentally broken, closing. |
In
system-accounts
triggers, we're usinggetent(1)
to check whetherthe username or group in question is existed before doing the heavy
lifting.
However,
getent(1)
will check the database in host system instead of ourrootfs, and by
PATH
manipulation logic, we prefer to useusr/bin/getent
inside our rootfs instead of host
getent(1)
.This is usually not a problem since we mostly run
xbps-triggers
ina real system instead of running from foreign system.
Except for
base-files
packages, which used to not have groupkvm
pre-allocated. Thus, requires running this trigger, and lead to all sort
of problems:
and we're bootstrapping a glibc one,
getent(1)
will be executable,however, when
getent(1)
attempt todlopen(3)
other libraries,it'll run into failure.
kvm
group pre-allocated (bootstrappingfrom 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 stopconfiguring
base-files
, not runningbase-files
'INSTALL
and leavethe 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)
andgroup(5)
is well-documented.