From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 11 19:10:34 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B8E47DF for ; Wed, 11 Jun 2014 19:10:34 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 99DB52A2B for ; Wed, 11 Jun 2014 19:10:34 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s5BJAYlk070210 for ; Wed, 11 Jun 2014 19:10:34 GMT (envelope-from bdrewery@freefall.freebsd.org) Received: (from bdrewery@localhost) by freefall.freebsd.org (8.14.9/8.14.9/Submit) id s5BJAYJ5070209 for freebsd-hackers@freebsd.org; Wed, 11 Jun 2014 19:10:34 GMT (envelope-from bdrewery) Received: (qmail 35105 invoked from network); 11 Jun 2014 14:10:32 -0500 Received: from unknown (HELO roundcube.xk42.net) (10.10.5.5) by sweb.xzibition.com with SMTP; 11 Jun 2014 14:10:32 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 11 Jun 2014 14:10:32 -0500 From: Bryan Drewery To: freebsd-hackers@freebsd.org Subject: Re: [RFC] Fixed installworld with noexec /tmp Organization: FreeBSD In-Reply-To: <5396C6A3.6050004@xenet.de> References: <25659df71b49c7b72b6f2d9a786c5ac9@shatow.net> <5396C6A3.6050004@xenet.de> Message-ID: X-Sender: bdrewery@FreeBSD.org User-Agent: Roundcube Webmail/0.9.5 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 19:10:34 -0000 On 2014-06-10 03:49, Matthias Meyser wrote: > Hi > > Am 10.06.2014 01:01, schrieb Bryan Drewery: >> I've always had my /tmp mounted as noexec. Despite how useless this >> is, I and many others have had trouble with installworld due to it. >> >> You can see how frequent it occurs here: >> https://www.google.com/#q=freebsd+installworld+noexec >> >> A simple workaround, which I only just discovered from PR 58117, is to >> set >> TMPDIR >> to somewhere that can exec. >> >> This patch fixes it by using the OBJDIR rather than the assumed /tmp >> or >> TMPDIR. >> >> The purpose of the installworld code using INSTALLTMP is to use the >> pre-install >> binaries to do the install, rather than the newly built binaries. This >> is to >> ensure >> the binaries will run while system is in an inconsistent state with >> libraries and >> in case the kernel is not yet upgraded. My change adds continues to >> respect >> that by >> ensuring it uses the already-installed mkdir(1) and env(1) with full >> paths. >> >> http://people.freebsd.org/~bdrewery/patches/installworld-noexec.txt >> >> --- Makefile.inc1 >> +++ Makefile.inc1 >> @@ -191,7 +191,9 @@ TMPPATH= ${STRICTTMPPATH}:${PATH} >> # when in the middle of installing over this system. >> # >> .if make(distributeworld) || make(installworld) >> -INSTALLTMP!= /usr/bin/mktemp -d -u -t install >> +INSTALLTMPDIR= ${OBJTREE}${.CURDIR}/itmp >> +INSTALLTMP!= /bin/mkdir -p ${INSTALLTMPDIR} && /usr/bin/env \ >> + TMPDIR=${INSTALLTMPDIR} /usr/bin/mktemp -d -u -t install >> .endif >> >> # >> @@ -833,7 +835,7 @@ distributeworld installworld: _installcheck_world >> LOCAL_MTREE=${LOCAL_MTREE:Q} distrib-dirs >> .endif >> ${_+_}cd ${.CURDIR}; ${IMAKE} re${.TARGET:S/world$//}; \ >> - ${IMAKEENV} rm -rf ${INSTALLTMP} >> + ${IMAKEENV} rm -rf ${INSTALLTMPDIR} >> .if make(distributeworld) >> .for dist in ${EXTRA_DISTRIBUTIONS} >> find ${DESTDIR}/${DISTDIR}/${dist} -mindepth 1 -empty -delete >> >> The only downside I see is that failures can leave the stale tmpdir in >> the OBJDIR, which is why I remove the entire "itmp" dir once >> installworld >> finally does succeed. >> > > Would this not break installing from an "RO" mounted OBJDIR? > > We build everything on one machine an install on many machines > by nfsmounting /usr/src/, /usr/doc, /usr/obj. > All of them are mounted "RO" to prevent changes during install. > > BW > Matthias Yes. I'll think about this some more. -- Regards, Bryan Drewery