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.


        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


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

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 \

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 \

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


As such, I'd suggest having a new user variable in mk.conf(5),


This way, we can replace _INSTALL_CACHE_REPO as suggested above and
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.


Reply via email to