On Tue, Dec 11, 2018 at 10:55:25PM +0100, Claudio Jeker wrote:
> 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
>
> I think the main issue is that /usr/sr/regress was not moved to the
> priv-drop security model. There is bunch of code which needs root but I
> don't want to run all of regress as user root.
There is a kind of mixed model there.
Because make build still goes thru regress for obj and cleandir
Yet the rest of the build doesn't!
So, if we agree that it needs to stay the way it currently is, then
the SUDO in that Makefile might trigger while running as root.......
... or we could change all the ports tree and rename SUDO to something
else in there so that it doesn't interfere at all. But I see most porters
not too happy with that choice.
As Mr Morden would say "what do you want ?"...
