Draft: doas and PACMAN_AUTH support. fix #105
#105 (closed) previously: !131 (closed) previously: 04af0374 in pacman: https://gitlab.archlinux.org/pacman/pacman/-/blob/master/scripts/makepkg.sh.in?ref_type=heads#L237
Merge request reports
Activity
I think support for PACMAN_AUTH is good and the best way to normalize this (in case you have both sudo/doas in your system), hence also included here.
I am not sure of a use case where keepenv is used. So not sure how to test.
Lastly, someone who actually uses PACMAN_AUTH, please test this patch before I remove the safeguards. It's a draft/WIP till then.
added 2 commits
-
0e2b16b0 - 1 commit from branch
archlinux:master
- b066eb18 - doas and PACMAN_AUTH support. fix #105 (closed)
-
0e2b16b0 - 1 commit from branch
added scopefeature label
This does not address !131 (comment 85795) it just works around it by not supporting it, which ends up creating unreproducible packages if
doas
is used.Secondly, there are still plenty of sudo invocations in devtools:
src/makechrootpkg.in: sudo --preserve-env=SOURCE_DATE_EPOCH \ src/makechrootpkg.in: --preserve-env=BUILDTOOL \ src/makechrootpkg.in: --preserve-env=BUILDTOOLVER \ src/makechrootpkg.in: sudo -u "$makepkg_user" --preserve-env=GNUPGHOME,SSH_AUTH_SOCK \
Used the same "trick" as
su
was using for the command escape, but added prefixed env vars.doas
doesn't support anything but a command, so usedsh -c
. 0dda1e3a have a prototype.interesting:
$ PACMAN_AUTH=sudo makechrootpkg -c -r $CHROOT ==> Synchronizing chroot copy [/home/gcb/chroot/root] -> [gcb]...done ==> Making package: fwupd 1.9.10.r640.g96cc2c6bc-1 (Wed May 22 10:07:23 2024) ==> Retrieving sources... -> Cloning fwupd-daemonless git repo... ... $? = 0
now forcing plain
doas
and havingpermitenv
in the conf:$ PACMAN_AUTH=doas makechrootpkg -c -r $CHROOT ==> Synchronizing chroot copy [/home/gcb/chroot/root] -> [copy]...done ==> ERROR: Running makepkg as root is not allowed. $? = 1
second case is doing nothing but using
doas
(with keepenv) in place ofsudo --preserve-env
There are a few places (like last comment) where business logic is tied to sudo. For now i just added DOAS_USER to the existing logic that uses SUDO_USERS :( Better solutions: make use of existing getopts that already cover the value, or pass via env vars like other things.
Then the other places sudo is used is to jump back from root to the makepkg_user. For now, i will not do anything since sudo package is required by all dev packages, so we are bound to have it anyway. What i'm trying to avoid is giving build users sudo access. This way the left over sudo calls are just from root->low user, which already work by default by simply installing the package. Better solutions: nspawn/systemd-run/other ways to just drop the uid (and maybe dropcaps) that are already used for other benefits in the build tools.
@gcb I managed to do a build in chroot with
doas
(viapkgctl build
). Somehowsudo
manages to pass$USER
in that exec call, so I added that tokeepenv
.Here's my patch against v1.2.1: doas.patch
Replacing
sudo --preserve-env
with$SUID_CMD env VAR1=$VAR1 ...
looks like is enough to make this agnostic?One more note, there's a
sudo
call which is run as root to switch back to the user. I had allow root to usedoas
:permit nopass keepenv root
Edited by Vladyslav Aviedov
mentioned in merge request !266