Hello ports@,
Today I spent a fair amount of time trying to understand why, after
having set relevant bits of configuration in /etc/doas.conf and
/etc/mk.conf, `make` was asking me for passwords.
Setup
=====
/etc/doas.conf:
permit persist lucas as root
permit nopass keepenv lucas as _pbuild
permit nopass keepenv lucas as _pfetch
permit nopass lucas cmd /usr/bin/touch
permit nopass setenv { TRUSTED_PKG_PATH TERM } \
lucas cmd /usr/sbin/pkg_add
permit nopass setenv { TERM } lucas cmd /usr/sbin/pkg_delete
/etc/mk.conf:
DISTDIR=/var/ports/distfiles
FETCH_PACKAGES=
PACKAGE_REPOSITORY=/var/ports/packages
PORTSDIR=/home/cvs/ports
PORTS_PRIVSEP=Yes
SUDO=doas
WRKOBJDIR=/var/ports/pobj
Ports tree is OPENBSD_6_6 and not -current, as I want a build machine
to backport some updates, to ease testing of ports updates (as in
packaging net/prosody 0.11.5 for testing it in my server which runs
-stable)
Note that I use some "unusual" paths. Reason for this is the machine
not being originally purposed to build packages, so I picked parts of
the filesystems that had spare space.
Debugging / solution proposals
==============================
After asking `ps auxww`, turns out the guilty is
doas install -d -o _pfetch -g 56 \
/var/ports/packages/amd64/cache/
which gets called at line 2084 of ports/infrastructure/mk/bsd.port.mk,
in some dependency chain (tbh, bsd.port.mk is a beast and I tried my
best to follow stuff).
So, first option would be adding another recommended line for
/etc/doas.conf in bsd.port.mk(5), in the same vein of the lines already
present in there.
Now, I don't feel to comfortable suggesting to add
permit nopass solene cmd install
to it. Instead, I'd prefer using full path, but that would require
changing that precise invocation of install to full path, or creating
a INSTALL_PROG variable, much like PKG_ADD and friends, defaulting to
/usr/bin/install. This will require, for consistency, changing all the
calls to install among all the makefiles to ${INSTALL_PROG}, which
seems quite invasive.
If we take a look at why that install gets called with doas, it happens
because PORTS_PRIVSEP is set to Yes, and so, the .if in line 133 of
ports/infrastructure/mk/pkgpath.mk sets _INSTALL_CACHE_REPO to escalate
privileges, in line 144. This call creates a directory owned by
${FETCH_USER}:${FETCH_USER}. This *could* be replace with
_INSTALL_CACHE_REPO = ${_PFETCH} install -d \
${PACKAGE_REPOSITORY_MODE}
which worked in my case, but I guess it's done with ${SUDO} because
${FETCH_USER} could not have write permissions in the directory where
the package cache gets created.
Which takes to the final alternative: ${_INSTALL_CACHE_REPO} is called
in only one place, line 2084 of bsd.port.mk. It's called with
${_CACHE_REPO}, assigned *unconditionally* at line 961 as
_CACHE_REPO = ${PACKAGE_REPOSITORY}/${MACHINE_ARCH}/cache/
As such, I'd suggest having a new user variable in mk.conf(5),
CACHE_REPOSITORY, and set
_CACHE_REPO = ${CACHE_REPOSITORY}/${MACHINE_ARCH}/cache/
This way, we can replace _INSTALL_CACHE_REPO as suggested above and
require CACHE_REPOSITORY to be owned by ${FETCH_USER} if PORTS_PRIVSEP
is Yes. We can also make fix-permissions handle the creation too.
Comments? Opinions? IMO introducing CACHE_REPOSITORY is quite clean and
the least invasive approach. I can prepare a patch for that.
-Lucas
