On Wed, Feb 03, 2021 at 08:29:31PM -0700, Thomas Frohwein wrote: > On Wed, Feb 03, 2021 at 09:23:48PM +0000, James Cook wrote: > > On Wed, Feb 03, 2021 at 07:24:08PM +0000, Stuart Henderson wrote: > > > On 2021/02/03 17:39, James Cook wrote: > > > > Hi ports@, > > > > > > > > Summary: I suggest the section at > > > > https://www.openbsd.org/faq/ports/ports.html#PortsConfig > > > > should include some additional text like the following: > > > > > > > > You will need to configure doas to pass the TRUSTED_PKG_PATH variable > > > > when running /usr/sbin/pkg_add. Adding the "nopass" option for > > > > certain commands can help reduce the number of times a password needs > > > > to be entered. For example, add the following to doas.conf(5), > > > > replacing "myuser" with your username: > > > > > > > > permit nopass myuser cmd /usr/bin/touch > > > > permit nopass setenv { TRUSTED_PKG_PATH TERM } myuser cmd > > > > /usr/sbin/pkg_add > > > > permit nopass setenv { TERM } myuser cmd /usr/sbin/pkg_delete > > > > > > Let's not go down the 'try to evaluate every variable' path again, > > > keepenv is the way to go, we have spent much time figuring out weird > > > bugs from missing variables in the past when we have tried to > > > evaluate them. > > > > > > If you are going to allow pkg_add with "nopass" you might just as well > > > write "permit nopass myuser". An account which can run pkg_add as root > > > has full control of the system. > > > > I don't have strong opinions about that. My point is just that the > > current documentation left me with a setup that didn't work. > > > > How about recommending keepenv instead, if that's better? > > I think sthen@ may have been a little too subtle about what a giant > footgun your proposal is. > > "permit nopass myuser" is equivalent to myuser being root and you might > as well run everything as root then and toss out all security > considerations that come from logging in as a non-root user. > > This has no place in the FAQ in my opinion.
I'll readily accept that it's a bad solution. I just thought I should suggest something instead of just complaining that the documentation is broken. Maybe I should back up and explain what led me to believe the documentation is broken. Maybe I'm mistaken, and the problem I ran into is my own fault. * The phrasing in this section: https://www.openbsd.org/faq/ports/ports.html#PortsConfig led me to believe I should try to configure privilege separation if I want to work with ports. * As a result, I set PORTS_PRIVSEP=Yes in /etc/mk.conf. * With that configuration, running "make install" in, say /usr/ports/archivers/gtar results in an error: falsifian angel gtar $ make install doas (falsif...@angel.falsifian.org) password: doas (falsif...@angel.falsifian.org) password: doas (falsif...@angel.falsifian.org) password: ===> Installing gtar-1.33p0 from /usr/ports/packages/amd64/all/ doas (falsif...@angel.falsifian.org) password: quirks-3.534 signed on 2021-02-03T00:42:33Z file:/usr/ports/packages/amd64/all/gtar-1.33p0.tgz: unsigned package Can't find /usr/ports/packages/amd64/all/gtar-1.33p0.tgz Couldn't install gtar-1.33p0 *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2148 '/var/db/pkg/gtar-1.33p0/+CONTENTS': @/usr/bin/env -i PKG_TMPDIR=/var/tmp TE...) doas (falsif...@angel.falsifian.org) password: *** Error 2 in /usr/ports/archivers/gtar (/usr/ports/infrastructure/mk/bsd.port.mk:2591 'install': @lock=gtar-1.33p0; export _LOCKS_HELD=" ...) Of course, now I know how to solve the error. But I thought I'd found a bug in the documentation, because the documentation led me to a bad setup. My suggested doas.conf comes (almost) directly from the existing documentation for PORTS_PRIVSEP. -- James
