On Tue, Dec 11, 2018 at 02:35:33PM -0700, Theo de Raadt wrote:
> Ted Unangst <t...@tedunangst.com> wrote:
>
> > Marc Espie wrote:
> > > > > - try to remove the files normally first
> > > > > rm -f ${SUDO_CLEAN} || test -z "${SUDO}" || ${SUDO} rm -f
> > > > > ${SUDO_CLEAN}
> > > > >
> > > > > this should actually fix the issue.
> > > > >
> > > > > Any other directory with that problem ?
> > > >
> > > > that fix the issue and the build continues fine
> > >
> > > So okay from source people ? tedu, guenther, theo, krw ? somebody else ?
> >
> > does anywhere else in the tree do this? aren't most (all) things either done
> > as root or not done as root?
>
> I also don't understand what the point is here.
>
> release(9) shows the correct build process.
>
> you start build as root, to permit the priv-drop security model we
> designed in 2017.
>
> If on the other hand you build from a regular user below, with doas
> configured to allow escalation at any point in time, the regular user
> below CAN ALWAYS BECOME ROOT SO YOU HAVE NO SECURITY MODEL IN MIND AT
> ALL, while you operate on Makefile and such you downloaded from elsewhere
>
> Such use of sudo/doas is an ANTI-PATTERN
Ah, so actually just
rm -f ${SUDO_CLEAN}
should be fine ?
